From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753663AbcITBLh (ORCPT ); Mon, 19 Sep 2016 21:11:37 -0400 Received: from mail-oi0-f49.google.com ([209.85.218.49]:34970 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753670AbcITBLe (ORCPT ); Mon, 19 Sep 2016 21:11:34 -0400 MIME-Version: 1.0 In-Reply-To: <20160920001215.GA91808@ast-mbp.thefacebook.com> References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-8-mic@digikod.net> <20160914210649.GA57174@ast-mbp.thefacebook.com> <57D9D6FE.4090708@digikod.net> <20160914232418.GD60248@ast-mbp.thefacebook.com> <57DB11B6.7090500@digikod.net> <20160920001215.GA91808@ast-mbp.thefacebook.com> From: Sargun Dhillon Date: Mon, 19 Sep 2016 18:10:52 -0700 Message-ID: Subject: Re: lsm naming dilemma. Re: [RFC v3 07/22] landlock: Handle file comparisons To: Alexei Starovoitov Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , LKML , Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, LSM , netdev , cgroups@vger.kernel.org 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 u8K1BfFL029568 I'm fine giving up the Checmate name. Landlock seems easy enough to Google. I haven't gotten a chance to look through the entire patchset yet, but it does seem like they are somewhat similar. On Mon, Sep 19, 2016 at 5:12 PM, Alexei Starovoitov wrote: > On Thu, Sep 15, 2016 at 11:25:10PM +0200, Mickaël Salaün wrote: >> >> Agreed. With this RFC, the Checmate features (i.e. network helpers) >> >> should be able to sit on top of Landlock. >> > >> > I think neither of them should be called fancy names for no technical reason. >> > We will have only one bpf based lsm. That's it and it doesn't >> > need an obscure name. Directory name can be security/bpf/..stuff.c >> >> I disagree on an LSM named "BPF". I first started with the "seccomp LSM" >> name (first RFC) but I later realized that it is confusing because >> seccomp is associated to its syscall and the underlying features. Same >> thing goes for BPF. It is also artificially hard to grep on a name too >> used in the kernel source tree. >> Making an association between the generic eBPF mechanism and a security >> centric approach (i.e. LSM) seems a bit reductive (for BPF). Moreover, >> the seccomp interface [1] can still be used. > > agree with above. > >> Landlock is a nice name to depict a sandbox as an enclave (i.e. a >> landlocked country/state). I want to keep this name, which is simple, >> express the goal of Landlock nicely and is comparable to other sandbox >> mechanisms as Seatbelt or Pledge. >> Landlock should not be confused with the underlying eBPF implementation. >> Landlock could use more than only eBPF in the future and eBPF could be >> used in other LSM as well. > > there will not be two bpf based LSMs. > Therefore unless you can convince Sargun to give up his 'checmate' name, > nothing goes in. > The features you both need are 90% the same, so they must be done > as part of single LSM whatever you both agree to call it. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sargun Dhillon Subject: Re: lsm naming dilemma. Re: [RFC v3 07/22] landlock: Handle file comparisons Date: Mon, 19 Sep 2016 18:10:52 -0700 Message-ID: References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-8-mic@digikod.net> <20160914210649.GA57174@ast-mbp.thefacebook.com> <57D9D6FE.4090708@digikod.net> <20160914232418.GD60248@ast-mbp.thefacebook.com> <57DB11B6.7090500@digikod.net> <20160920001215.GA91808@ast-mbp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , LKML , Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, To: Alexei Starovoitov Return-path: In-Reply-To: <20160920001215.GA91808@ast-mbp.thefacebook.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org I'm fine giving up the Checmate name. Landlock seems easy enough to Google. I haven't gotten a chance to look through the entire patchset yet, but it does seem like they are somewhat similar. On Mon, Sep 19, 2016 at 5:12 PM, Alexei Starovoitov wrote: > On Thu, Sep 15, 2016 at 11:25:10PM +0200, Micka=C3=ABl Sala=C3=BCn wrote: >> >> Agreed. With this RFC, the Checmate features (i.e. network helpers) >> >> should be able to sit on top of Landlock. >> > >> > I think neither of them should be called fancy names for no technical = reason. >> > We will have only one bpf based lsm. That's it and it doesn't >> > need an obscure name. Directory name can be security/bpf/..stuff.c >> >> I disagree on an LSM named "BPF". I first started with the "seccomp LSM" >> name (first RFC) but I later realized that it is confusing because >> seccomp is associated to its syscall and the underlying features. Same >> thing goes for BPF. It is also artificially hard to grep on a name too >> used in the kernel source tree. >> Making an association between the generic eBPF mechanism and a security >> centric approach (i.e. LSM) seems a bit reductive (for BPF). Moreover, >> the seccomp interface [1] can still be used. > > agree with above. > >> Landlock is a nice name to depict a sandbox as an enclave (i.e. a >> landlocked country/state). I want to keep this name, which is simple, >> express the goal of Landlock nicely and is comparable to other sandbox >> mechanisms as Seatbelt or Pledge. >> Landlock should not be confused with the underlying eBPF implementation. >> Landlock could use more than only eBPF in the future and eBPF could be >> used in other LSM as well. > > there will not be two bpf based LSMs. > Therefore unless you can convince Sargun to give up his 'checmate' name, > nothing goes in. > The features you both need are 90% the same, so they must be done > as part of single LSM whatever you both agree to call it. > From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: <20160920001215.GA91808@ast-mbp.thefacebook.com> References: <20160914072415.26021-1-mic@digikod.net> <20160914072415.26021-8-mic@digikod.net> <20160914210649.GA57174@ast-mbp.thefacebook.com> <57D9D6FE.4090708@digikod.net> <20160914232418.GD60248@ast-mbp.thefacebook.com> <57DB11B6.7090500@digikod.net> <20160920001215.GA91808@ast-mbp.thefacebook.com> From: Sargun Dhillon Date: Mon, 19 Sep 2016 18:10:52 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kernel-hardening] Re: lsm naming dilemma. Re: [RFC v3 07/22] landlock: Handle file comparisons To: Alexei Starovoitov Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , LKML , Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , "Serge E . Hallyn" , Tejun Heo , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, LSM , netdev , cgroups@vger.kernel.org List-ID: I'm fine giving up the Checmate name. Landlock seems easy enough to Google. I haven't gotten a chance to look through the entire patchset yet, but it does seem like they are somewhat similar. On Mon, Sep 19, 2016 at 5:12 PM, Alexei Starovoitov wrote: > On Thu, Sep 15, 2016 at 11:25:10PM +0200, Micka=C3=ABl Sala=C3=BCn wrote: >> >> Agreed. With this RFC, the Checmate features (i.e. network helpers) >> >> should be able to sit on top of Landlock. >> > >> > I think neither of them should be called fancy names for no technical = reason. >> > We will have only one bpf based lsm. That's it and it doesn't >> > need an obscure name. Directory name can be security/bpf/..stuff.c >> >> I disagree on an LSM named "BPF". I first started with the "seccomp LSM" >> name (first RFC) but I later realized that it is confusing because >> seccomp is associated to its syscall and the underlying features. Same >> thing goes for BPF. It is also artificially hard to grep on a name too >> used in the kernel source tree. >> Making an association between the generic eBPF mechanism and a security >> centric approach (i.e. LSM) seems a bit reductive (for BPF). Moreover, >> the seccomp interface [1] can still be used. > > agree with above. > >> Landlock is a nice name to depict a sandbox as an enclave (i.e. a >> landlocked country/state). I want to keep this name, which is simple, >> express the goal of Landlock nicely and is comparable to other sandbox >> mechanisms as Seatbelt or Pledge. >> Landlock should not be confused with the underlying eBPF implementation. >> Landlock could use more than only eBPF in the future and eBPF could be >> used in other LSM as well. > > there will not be two bpf based LSMs. > Therefore unless you can convince Sargun to give up his 'checmate' name, > nothing goes in. > The features you both need are 90% the same, so they must be done > as part of single LSM whatever you both agree to call it. >