Date: Wed, 6 Nov 2019 17:58:46 +0100 From: Mickaël Salaün <mic@...ikod.net> To: KP Singh <kpsingh@...omium.org> Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, linux-kernel@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>, Andy Lutomirski <luto@...capital.net>, Casey Schaufler <casey@...aufler-ca.com>, Daniel Borkmann <daniel@...earbox.net>, David Drysdale <drysdale@...gle.com>, Florent Revest <revest@...omium.org>, James Morris <jmorris@...ei.org>, Jann Horn <jann@...jh.net>, John Johansen <john.johansen@...onical.com>, Jonathan Corbet <corbet@....net>, Kees Cook <keescook@...omium.org>, Michael Kerrisk <mtk.manpages@...il.com>, Mickaël Salaün <mickael.salaun@....gouv.fr>, Paul Moore <paul@...l-moore.com>, Sargun Dhillon <sargun@...gun.me>, "Serge E . Hallyn" <serge@...lyn.com>, Shuah Khan <shuah@...nel.org>, Stephen Smalley <sds@...ho.nsa.gov>, Tejun Heo <tj@...nel.org>, Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, Tycho Andersen <tycho@...ho.ws>, Will Drewry <wad@...omium.org>, bpf@...r.kernel.org, kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org, linux-security-module@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks On 06/11/2019 11:15, KP Singh wrote: > On 05-Nov 19:01, Mickaël Salaün wrote: >> On 05/11/2019 18:18, Alexei Starovoitov wrote: [...] >>> >>> I think the only way bpf-based LSM can land is both landlock and KRSI >>> developers work together on a design that solves all use cases. >> >> As I said in a previous cover letter , that would be great. I think >> that the current Landlock bases (almost everything from this series >> except the seccomp interface) should meet both needs, but I would like >> to have the point of view of the KRSI developers. > > As I mentioned we are willing to collaborate but the current landlock > patches does not meet the needs for KRSI: > > * One program type per use-case (eg. LANDLOCK_PROG_PTRACE) as opposed to > a single program type. This is something that KRSI proposed in it's > initial design  and the new common "eBPF + LSM" based approach >  would maintain as well. As ask in my previous email , I don't see how KRSI would efficiently deal with other LSM hooks with a unique program (attach) type.  https://email@example.com/ > > * Landlock chooses to have multiple LSM hooks per landlock hook which is > more restrictive. It's not easy to write precise MAC and Audit > policies for a privileged LSM based on this and this ends up bloating > the context that needs to be maintained and requires avoidable > boilerplate work in the kernel. Why do you think it is more restrictive or it adds boilerplate work? How does KRSI will deal with more complex hooks than execve-like with multiple kernel objects? > >  https://lore.kernel.org/patchwork/project/lkml/list/?series=410101 >  https://lore.kernel.org/bpf/20191106100655.GA18815@chromium.org/T/#u > > - KP Singh
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.