From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752994AbcJCXwq (ORCPT ); Mon, 3 Oct 2016 19:52:46 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:37066 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521AbcJCXwf (ORCPT ); Mon, 3 Oct 2016 19:52:35 -0400 MIME-Version: 1.0 In-Reply-To: <57D9D06C.2020007@digikod.net> References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-12-mic@digikod.net> <57D9D06C.2020007@digikod.net> From: Kees Cook Date: Mon, 3 Oct 2016 16:52:32 -0700 X-Google-Sender-Auth: 9IJxKZAvpQDeT-JfDZaoM-igE0A Message-ID: Subject: Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , "kernel-hardening@lists.openwall.com" , Linux API , LSM List , Network Development , "open list:CONTROL GROUP (CGROUP)" , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u93Nqokt004576 On Wed, Sep 14, 2016 at 3:34 PM, Mickaël Salaün wrote: > > On 14/09/2016 20:43, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >>> A Landlock program will be triggered according to its subtype/origin >>> bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the >>> Landlock program when a seccomp filter will return RET_LANDLOCK. >>> Moreover, it is possible to return a 16-bit cookie which will be >>> readable by the Landlock programs in its context. >> >> Are you envisioning that the filters will return RET_LANDLOCK most of >> the time or rarely? If it's most of the time, then maybe this could >> be simplified a bit by unconditionally calling the landlock filter and >> letting the landlock filter access a struct seccomp_data if needed. > > Exposing seccomp_data in a Landlock context may be a good idea. The main > implication is that Landlock programs may then be architecture specific > (if dealing with data) as seccomp filters are. Another point is that it > remove any direct binding between seccomp filters and Landlock programs. > I will try this (more simple) approach. Yeah, I would prefer that the seccomp code isn't doing list management to identify the landlock hooks to trigger, etc. I think that's better done on the LSM side. And since multiple seccomp filters could trigger landlock, it may be best to just leave the low 16 bits unused entirely. Then all state management is handled by the landlock eBPF maps, not a value coming from seccomp that can get stomped on by new filters, etc. -Kees -- Kees Cook Nexus Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy Date: Mon, 3 Oct 2016 16:52:32 -0700 Message-ID: References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-12-mic@digikod.net> <57D9D06C.2020007@digikod.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , "kernel-hardening@lists.openwall.com" , Linux API < To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Return-path: Received: from mail-wm0-f50.google.com ([74.125.82.50]:37986 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751500AbcJCXwf (ORCPT ); Mon, 3 Oct 2016 19:52:35 -0400 Received: by mail-wm0-f50.google.com with SMTP id p138so180098829wmb.1 for ; Mon, 03 Oct 2016 16:52:34 -0700 (PDT) In-Reply-To: <57D9D06C.2020007@digikod.net> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Sep 14, 2016 at 3:34 PM, Micka=C3=ABl Sala=C3=BCn = wrote: > > On 14/09/2016 20:43, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Micka=C3=ABl Sala=C3=BCn wrote: >>> A Landlock program will be triggered according to its subtype/origin >>> bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the >>> Landlock program when a seccomp filter will return RET_LANDLOCK. >>> Moreover, it is possible to return a 16-bit cookie which will be >>> readable by the Landlock programs in its context. >> >> Are you envisioning that the filters will return RET_LANDLOCK most of >> the time or rarely? If it's most of the time, then maybe this could >> be simplified a bit by unconditionally calling the landlock filter and >> letting the landlock filter access a struct seccomp_data if needed. > > Exposing seccomp_data in a Landlock context may be a good idea. The main > implication is that Landlock programs may then be architecture specific > (if dealing with data) as seccomp filters are. Another point is that it > remove any direct binding between seccomp filters and Landlock programs. > I will try this (more simple) approach. Yeah, I would prefer that the seccomp code isn't doing list management to identify the landlock hooks to trigger, etc. I think that's better done on the LSM side. And since multiple seccomp filters could trigger landlock, it may be best to just leave the low 16 bits unused entirely. Then all state management is handled by the landlock eBPF maps, not a value coming from seccomp that can get stomped on by new filters, etc. -Kees --=20 Kees Cook Nexus Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy Date: Mon, 3 Oct 2016 16:52:32 -0700 Message-ID: References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-12-mic@digikod.net> <57D9D06C.2020007@digikod.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <57D9D06C.2020007@digikod.net> Sender: netdev-owner@vger.kernel.org To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , "kernel-hardening@lists.openwall.com" List-Id: linux-api@vger.kernel.org On Wed, Sep 14, 2016 at 3:34 PM, Micka=C3=ABl Sala=C3=BCn = wrote: > > On 14/09/2016 20:43, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Micka=C3=ABl Sala=C3=BCn wrote: >>> A Landlock program will be triggered according to its subtype/origin >>> bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the >>> Landlock program when a seccomp filter will return RET_LANDLOCK. >>> Moreover, it is possible to return a 16-bit cookie which will be >>> readable by the Landlock programs in its context. >> >> Are you envisioning that the filters will return RET_LANDLOCK most of >> the time or rarely? If it's most of the time, then maybe this could >> be simplified a bit by unconditionally calling the landlock filter and >> letting the landlock filter access a struct seccomp_data if needed. > > Exposing seccomp_data in a Landlock context may be a good idea. The main > implication is that Landlock programs may then be architecture specific > (if dealing with data) as seccomp filters are. Another point is that it > remove any direct binding between seccomp filters and Landlock programs. > I will try this (more simple) approach. Yeah, I would prefer that the seccomp code isn't doing list management to identify the landlock hooks to trigger, etc. I think that's better done on the LSM side. And since multiple seccomp filters could trigger landlock, it may be best to just leave the low 16 bits unused entirely. Then all state management is handled by the landlock eBPF maps, not a value coming from seccomp that can get stomped on by new filters, etc. -Kees --=20 Kees Cook Nexus Security From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <57D9D06C.2020007@digikod.net> References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-12-mic@digikod.net> <57D9D06C.2020007@digikod.net> From: Kees Cook Date: Mon, 3 Oct 2016 16:52:32 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kernel-hardening] Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , "kernel-hardening@lists.openwall.com" , Linux API , LSM List , Network Development , "open list:CONTROL GROUP (CGROUP)" , Andrew Morton List-ID: On Wed, Sep 14, 2016 at 3:34 PM, Micka=C3=ABl Sala=C3=BCn = wrote: > > On 14/09/2016 20:43, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Micka=C3=ABl Sala=C3=BCn wrote: >>> A Landlock program will be triggered according to its subtype/origin >>> bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the >>> Landlock program when a seccomp filter will return RET_LANDLOCK. >>> Moreover, it is possible to return a 16-bit cookie which will be >>> readable by the Landlock programs in its context. >> >> Are you envisioning that the filters will return RET_LANDLOCK most of >> the time or rarely? If it's most of the time, then maybe this could >> be simplified a bit by unconditionally calling the landlock filter and >> letting the landlock filter access a struct seccomp_data if needed. > > Exposing seccomp_data in a Landlock context may be a good idea. The main > implication is that Landlock programs may then be architecture specific > (if dealing with data) as seccomp filters are. Another point is that it > remove any direct binding between seccomp filters and Landlock programs. > I will try this (more simple) approach. Yeah, I would prefer that the seccomp code isn't doing list management to identify the landlock hooks to trigger, etc. I think that's better done on the LSM side. And since multiple seccomp filters could trigger landlock, it may be best to just leave the low 16 bits unused entirely. Then all state management is handled by the landlock eBPF maps, not a value coming from seccomp that can get stomped on by new filters, etc. -Kees --=20 Kees Cook Nexus Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy Date: Mon, 3 Oct 2016 16:52:32 -0700 Message-ID: References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-12-mic@digikod.net> <57D9D06C.2020007@digikod.net> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=GKgeyJFFvBinrT8m6mkOYxXbaQogbNBHsbDiPZWqJ4k=; b=ZInVasRizuDeAg2bzkWQo84gX167P9ZRVVnkB/3W9P648A86EJqe4nzKwuE3qZrf6Q 9n34gFM7paJVrqHKbFC7ofH7vzafAAHHuZKsHAZzmicPPVpiypLim1hRZswQF/DaDw4m XGW0cOllaQx/4N035/sS1GUDNE1oiPokUFDoJ2TBF2zsjKASztxB6aHchJOI0EWBbaVB ZFbSGu/VIIzTLC+7niF/IENnehdJ5b5L4swSoat91+JfIibnLB4MetGzQB4PRokMY6S4 bBZ91DRblveGbENDpFrSs2NSrUopH8E86sJyQ6QIfGtutpoVRWTH/7cWMCCQwtd0o/1C re0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=GKgeyJFFvBinrT8m6mkOYxXbaQogbNBHsbDiPZWqJ4k=; b=K4H+/wUp7L/4257E1NKnPFLfGm9FEUN0ZRK5KP5n7Wi2NwAnLLSlNk84OxODJumVU2 6rL/bUYdN3T8D9kTN1w+kP1WdXt3Suc42j56d4sdXoBEXAGlzYxGNdmy1A6+o/tDlViW /IlKBbJ+Otw/7eSXwBOHt/BbvWWJCETLAVgJg= In-Reply-To: <57D9D06C.2020007@digikod.net> Sender: netdev-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , "kernel-hardening@lists.openwall.com" , Linux API <> On Wed, Sep 14, 2016 at 3:34 PM, Micka=C3=ABl Sala=C3=BCn = wrote: > > On 14/09/2016 20:43, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Micka=C3=ABl Sala=C3=BCn wrote: >>> A Landlock program will be triggered according to its subtype/origin >>> bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the >>> Landlock program when a seccomp filter will return RET_LANDLOCK. >>> Moreover, it is possible to return a 16-bit cookie which will be >>> readable by the Landlock programs in its context. >> >> Are you envisioning that the filters will return RET_LANDLOCK most of >> the time or rarely? If it's most of the time, then maybe this could >> be simplified a bit by unconditionally calling the landlock filter and >> letting the landlock filter access a struct seccomp_data if needed. > > Exposing seccomp_data in a Landlock context may be a good idea. The main > implication is that Landlock programs may then be architecture specific > (if dealing with data) as seccomp filters are. Another point is that it > remove any direct binding between seccomp filters and Landlock programs. > I will try this (more simple) approach. Yeah, I would prefer that the seccomp code isn't doing list management to identify the landlock hooks to trigger, etc. I think that's better done on the LSM side. And since multiple seccomp filters could trigger landlock, it may be best to just leave the low 16 bits unused entirely. Then all state management is handled by the landlock eBPF maps, not a value coming from seccomp that can get stomped on by new filters, etc. -Kees --=20 Kees Cook Nexus Security