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 <alexei.starovoitov@xxxxxxxxx> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
