On Thu, Nov 12, 2020 at 9:52 PM Mickaël Salaün mic@digikod.net 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@arndb.de Cc: James Morris jmorris@namei.org Cc: Jann Horn jannh@google.com Cc: Kees Cook keescook@chromium.org Cc: Serge E. Hallyn serge@hallyn.com Signed-off-by: Mickaël Salaün mic@linux.microsoft.com
Reviewed-by: Jann Horn jannh@google.com