On Thu, Nov 12, 2020 at 9:52 PM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > These 3 system calls are designed to be used by unprivileged processes > to sandbox themselves: > * landlock_create_ruleset(2): Creates a ruleset and returns its file > descriptor. > * landlock_add_rule(2): Adds a rule (e.g. file hierarchy access) to a > ruleset, identified by the dedicated file descriptor. > * landlock_enforce_ruleset_current(2): Enforces a ruleset on the current > thread and its future children (similar to seccomp). This syscall has > the same usage restrictions as seccomp(2): the caller must have the > no_new_privs attribute set or have CAP_SYS_ADMIN in the current user > namespace. > > All these syscalls have a "flags" argument (not currently used) to > enable extensibility. > > Here are the motivations for these new syscalls: > * A sandboxed process may not have access to file systems, including > /dev, /sys or /proc, but it should still be able to add more > restrictions to itself. > * Neither prctl(2) nor seccomp(2) (which was used in a previous version) > fit well with the current definition of a Landlock security policy. > > All passed structs (attributes) are checked at build time to ensure that > they don't contain holes and that they are aligned the same way for each > architecture. > > See the user and kernel documentation for more details (provided by a > following commit): > * Documentation/userspace-api/landlock.rst > * Documentation/security/landlock.rst > > Cc: Arnd Bergmann <arnd@xxxxxxxx> > Cc: James Morris <jmorris@xxxxxxxxx> > Cc: Jann Horn <jannh@xxxxxxxxxx> > Cc: Kees Cook <keescook@xxxxxxxxxxxx> > Cc: Serge E. Hallyn <serge@xxxxxxxxxx> > Signed-off-by: Mickaël Salaün <mic@xxxxxxxxxxxxxxxxxxx> Reviewed-by: Jann Horn <jannh@xxxxxxxxxx>
