Re: [PATCH v1] landlock: Document the threat model

["Mickaël Salaün" <mic@digikod.net>]

On Wed, Jul 08, 2026 at 11:48:09PM +0200, Jann Horn wrote:
> On Tue, Jul 7, 2026 at 11:03 PM Mickaël Salaün <mic@digikod.net> wrote:
> > +Sandboxing is layered
> > +---------------------
> > +
> > +Landlock is the access-control layer of a sandbox, not the whole sandbox.  A
> > +robust sandbox also needs steps that are the program's responsibility: switching
> > +to an unprivileged user, dropping capabilities, setting ``PR_SET_NO_NEW_PRIVS``,
> > +and confining all threads of the process with the same domain.  A
> > +single-threaded process gets the latter for free; a multithreaded one can
> > +enforce a ruleset atomically on all its threads, or must otherwise synchronize
> > +them before any untrusted work.  Landlock is typically applied last, to tighten
> > +access and make the domain identifiable and auditable.
> > +
> > +Stronger isolation can come from combining Landlock with other mechanisms in a
> > +defense-in-depth approach, notably seccomp-bpf (see
> > +Documentation/userspace-api/seccomp_filter.rst) for what Landlock does not yet
> > +cover.  A long-term goal of Landlock is to control access to any kind of kernel
> > +resource in a way suited to sandboxing.
> 
> I think this part is something that should go near the top of the
> document, and should have a title like "How to securely use landlock"
> - most of the document is focused on telling kernel developers or
> security researchers what the boundaries of the threat model are, but

This patch is really about the threat model, to make it clear to
kernel developers, security researchers, and especially to AI agents
(not sure it will work but at least we can point to a specific doc),
what is not a Landlock security bug and why.

> I think it is also important (and maybe even more important) to
> present this from the perspective of "if I want to design a sandbox
> using landlock, what do I need to pay attention to".

I agree that it's more important, but the correct doc for that would be
the userspace API doc, which already describes how to use Landlock.
That would be an independent patch though.

> 
> I think it would also make sense to give more specific guidance on
> which sets of syscalls, with what argument restrictions, can be
> permitted in a seccomp policy because landlock covers any accesses
> that these syscalls can perform to objects to which the process
> doesn't already hold file descriptors or such.
> I think it would be helpful to have instructions like "you can safely
> allow socket operations if you ensure that socket creation (socket())
> only works for AF_UNIX, and that the process has no existing socket
> file descriptors for non-covered socket types, and you have fs_access
> rules, and the kernel is sufficiently recent".

I'm wondering how we could have such a doc without gaps, make it simple
to read, and keep it up-to-date for all kernel versions and
architectures.  Another challenge would also be to map these syscalls
and arguments to the evolving set of Landlock access rights.  I think
the most pragmatic approach would be to rely on a dedicated library, but
maintaining it with a complete test coverage looks like a nightmare.