Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 13 Nov 2016 09:38:11 -0800
From: Alexei Starovoitov <>
To: Mickaël Salaün <>
Cc: "" <>, Alexei Starovoitov <>, 
	Andy Lutomirski <>, Daniel Borkmann <>, 
	Daniel Mack <>, David Drysdale <>, 
	"David S . Miller" <>, "Eric W . Biederman" <>, 
	James Morris <>, Jann Horn <>, 
	Kees Cook <>, Paul Moore <>, 
	Sargun Dhillon <>, "Serge E . Hallyn" <>, Tejun Heo <>, 
	Thomas Graf <>, Will Drewry <>,, 
	Linux API <>, 
	LSM List <>, 
	"" <>, 
	"open list:CONTROL GROUP (CGROUP)" <>
Subject: Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing

On Sun, Nov 13, 2016 at 6:23 AM, Mickaël Salaün <> 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.