[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJURKRFbNiVTJ76XUWZ=P+DqyP0QMVZrCutzvS28bkhGw@mail.gmail.com>
Date: Sun, 13 Nov 2016 09:38:11 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
Andy Lutomirski <luto@...capital.net>, Daniel Borkmann <daniel@...earbox.net>,
Daniel Mack <daniel@...que.org>, David Drysdale <drysdale@...gle.com>,
"David S . Miller" <davem@...emloft.net>, "Eric W . Biederman" <ebiederm@...ssion.com>,
James Morris <james.l.morris@...cle.com>, Jann Horn <jann@...jh.net>,
Kees Cook <keescook@...omium.org>, Paul Moore <pmoore@...hat.com>,
Sargun Dhillon <sargun@...gun.me>, "Serge E . Hallyn" <serge@...lyn.com>, Tejun Heo <tj@...nel.org>,
Thomas Graf <tgraf@...g.ch>, Will Drewry <wad@...omium.org>, kernel-hardening@...ts.openwall.com,
Linux API <linux-api@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>
Subject: Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing
On Sun, Nov 13, 2016 at 6:23 AM, Mickaël Salaün <mic@...ikod.net> wrote:
> Hi,
>
> After the BoF at LPC last week, we came to a multi-step roadmap to
> upstream Landlock.
>
> A first patch series containing the basic properties needed for a
> "minimum viable product", which means being able to test it, without
> full features. The idea is to set in place the main components which
> include the LSM part (some hooks with the manager logic) and the new
> eBPF type. To have a minimum amount of code, the first userland entry
> point will be the seccomp syscall. This doesn't imply non-upstream
> patches and should be more simple. For the sake of simplicity and to
> ease the review, this first series will only be dedicated to privileged
> processes (i.e. with CAP_SYS_ADMIN). We may want to only allow one level
> of rules at first, instead of dealing with more complex rule inheritance
> (like seccomp-bpf can do).
>
> The second series will focus on the cgroup manager. It will follow the
> same rules of inheritance as the Daniel Mack's patches does.
>
> The third series will try to bring a BPF map of handles for Landlock and
> the dedicated BPF helpers.
>
> Finally, the fourth series will bring back the unprivileged mode (with
> no_new_privs), at least for process hierarchies (via seccomp). This also
> imply to handle multi-level of rules.
>
> Right now, an important point of attention is the userland ABI. We don't
> want LSM hooks to be exposed "as is" to userland. This may have some
> future implications if their semantic and/or enforcement point(s)
> change. In the next series, I will propose a new abstraction over the
> currently used LSM hooks. I'll also propose a new way to deal with
> resource accountability. Finally, I plan to create a minimal (kernel)
> developer documentation and a test suite.
Thanks for the summary.
That's exactly what we discussed and agreed upon.
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.
