On Thu, Nov 12, 2020 at 9:52 PM Mickaël Salaün <[email protected]> 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 <[email protected]> > Cc: James Morris <[email protected]> > Cc: Jann Horn <[email protected]> > Cc: Kees Cook <[email protected]> > Cc: Serge E. Hallyn <[email protected]> > Signed-off-by: Mickaël Salaün <[email protected]>
Reviewed-by: Jann Horn <[email protected]>
