Hi,
This updated patch series relaxes landlock_add_rule(2) to accept file
descriptors opened without O_PATH. Using O_PATH is encouraged (as well
as O_CLOEXEC) but it should not be mandatory. Indeed, using already
opened FDs can be handy.
FYI, the COND_SYSCALL() fix is now in -next:
https://git.kernel.org/next/linux-next/c/7dfe553affd0d003c7535b7ba60d09193471ea9d
James, could you please update the -next tree?
The SLOC count is 1326 for security/landlock/ and 2589 for
tools/testing/selftest/landlock/ .
Test coverage for security/landlock/ is 93.6% of lines:
https://landlock.io/linux-lcov/landlock-v33/security/landlock/index.html
The code not covered only deals with internal kernel errors (e.g. memory
allocation), race conditions and safety checks that should not be
triggered. This series is being fuzzed by syzkaller (covering internal
kernel errors) that now supports Landlock:
https://github.com/google/syzkaller/pull/2380
syzkaller coverage is about 72% (ci-upstream-linux-next-kasan-gce-root):
https://syzkaller.appspot.com/upstream
The HTML documentation is available here:
https://landlock.io/linux-doc/landlock-v33/userspace-api/landlock.html
This series can be applied on top of v5.12-rc3 . This can be tested with
CONFIG_SECURITY_LANDLOCK, CONFIG_SAMPLE_LANDLOCK and by prepending
"landlock," to CONFIG_LSM. This patch series can be found in a Git
repository here:
https://github.com/landlock-lsm/linux/commits/landlock-v33
This patch series seems ready for upstream and I would really appreciate
final reviews.
Landlock LSM
The goal of Landlock is to enable to restrict ambient rights (e.g.
global filesystem access) for a set of processes. Because Landlock is a
stackable LSM [1], it makes possible to create safe security sandboxes
as new security layers in addition to the existing system-wide
access-controls. This kind of sandbox is expected to help mitigate the
security impact of bugs or unexpected/malicious behaviors in user-space
applications. Landlock empowers any process, including unprivileged
ones, to securely restrict themselves.
Landlock is inspired by seccomp-bpf but instead of filtering syscalls
and their raw arguments, a Landlock rule can restrict the use of kernel
objects like file hierarchies, according to the kernel semantic.
Landlock also takes inspiration from other OS sandbox mechanisms: XNU
Sandbox, FreeBSD Capsicum or OpenBSD Pledge/Unveil.
In this current form, Landlock misses some access-control features.
This enables to minimize this patch series and ease review. This series
still addresses multiple use cases, especially with the combined use of
seccomp-bpf: applications with built-in sandboxing, init systems,
security sandbox tools and security-oriented APIs [2].
[1]
https://lore.kernel.org/lkml/50db058a-7dde-441b-a7f9-f6837fe8b...@schaufler-ca.com/
[2]
https://lore.kernel.org/lkml/f646e1c7-33cf-333f-070c-0a40ad046...@digikod.net/
Previous versions:
v32: https://lore.kernel.org/lkml/20210401205208.2756565-1-...@digikod.net/
v31: https://lore.kernel.org/lkml/20210324191520.125779-1-...@digikod.net/
v30: https://lore.kernel.org/lkml/20210316204252.427806-1-...@digikod.net/
v29: https://lore.kernel.org/lkml/20210225190614.2181147-1-...@digikod.net/
v28: https://lore.kernel.org/lkml/20210202162710.657398-1-...@digikod.net/
v27: https://lore.kernel.org/lkml/20210121205119.793296-1-...@digikod.net/
v26: https://lore.kernel.org/lkml/20201209192839.1396820-1-...@digikod.net/
v25: https://lore.kernel.org/lkml/20201201192322.213239-1-...@digikod.net/
v24: https://lore.kernel.org/lkml/20201112205141.775752-1-...@digikod.net/
v23: https://lore.kernel.org/lkml/20201103182109.1014179-1-...@digikod.net/
v22: https://lore.kernel.org/lkml/20201027200358.557003-1-...@digikod.net/
v21: https://lore.kernel.org/lkml/20201008153103.1155388-1-...@digikod.net/
v20: https://lore.kernel.org/lkml/20200802215903.91936-1-...@digikod.net/
v19: https://lore.kernel.org/lkml/20200707180955.53024-1-...@digikod.net/
v18: https://lore.kernel.org/lkml/20200526205322.23465-1-...@digikod.net/
v17: https://lore.kernel.org/lkml/20200511192156.1618284-1-...@digikod.net/
v16: https://lore.kernel.org/lkml/20200416103955.145757-1-...@digikod.net/
v15: https://lore.kernel.org/lkml/20200326202731.693608-1-...@digikod.net/
v14: https://lore.kernel.org/lkml/20200224160215.4136-1-...@digikod.net/
v13: https://lore.kernel.org/lkml/20191104172146.30797-1-...@digikod.net/
v12: https://lore.kernel.org/lkml/20191031164445.29426-1-...@digikod.net/
v11: https://lore.kernel.org/lkml/20191029171505.6650-1-...@digikod.net/
v10: https://lore.kernel.org/lkml/20190721213116.23476-1-...@digikod.net/
v9: https://lore.kernel.org/lkml/20190625215239.11136-1-...@digikod.net/
v8: https://lore.kernel.org/lkml/20180227004121.3633-1-...@digikod.net/
v7: https://lore.kernel.org/lkml/20170821000933.13024-1-...@digikod.net/
v6: https://lore.kernel.org/lkml/20170328234650.19695-1-...@digikod.net/
v5:
