LWN: Comments on "Landlock (finally) sets sail"

Landlock (finally) sets sail

l0kod — Mon, 28 Jun 2021 11:36:42 +0000

It is an incremental development; we can't push a big chunk of new code, especially for security features, which should also come with exhaustive documentation, tests and reviews. BTW, most Linux access-control mechanisms don't handle every possible access-control types. It is also an opportunity to take into account different use cases and wish lists. Anyhow, Landlock is already useful, the current limitations are explicit, and sandboxing can be improved thanks to features such as seccomp.

Landlock (finally) sets sail

aabc — Sun, 27 Jun 2021 23:18:28 +0000

> Landlock is useful in its current form, but ...

"It is currently not possible to restrict some file-related actions accessible through these syscall families: chdir(2), truncate(2), stat(2), flock(2), chmod(2), chown(2), setxattr(2), utime(2), ioctl(2), fcntl(2), access(2). Future Landlock evolutions will enable to restrict them."

Landlock (finally) sets sail

l0kod — Fri, 25 Jun 2021 15:55:40 +0000

That is a reasonable concern and it was actually addressed by a previous version of Landlock with a dedicated syscall to get the set of available features. However, this approach was drastically simplified with the current version that only deal with a monotonic version, which is enough for the objective.

Downstream users (e.g. distros) should not cherry-pick arbitrary features from Linux mainline without measuring the potential consequences. If they do so, they are responsible for the new forked kernel they create. It would also be a risk (and it seems weird, and it may be too cumbersome) for them to only pick partial features instead of the whole new features up to a point. This responsibility also requires to run kernel tests, including Landlock ones. I'll do my best to maintain consistent tests, including version checks that are and will be part of the feature tests.

Landlock (finally) sets sail

ecree — Thu, 24 Jun 2021 20:34:38 +0000

LANDLOCK_CREATE_RULESET_VERSION sounds like something that will work fine until the first time a distro kernel starts backporting Landlock features. How willing will distros be to only ever take progress monotonically, and how likely are they not to screw it up by mistake?

Landlock (finally) sets sail

l0kod — Tue, 22 Jun 2021 06:39:13 +0000

Indeed, I was mostly referring to OpenBSD Unveil (enabling file system access-control), the complement to Pledge (enabling other coarse grained access-control types).

Landlock (finally) sets sail

timrichardson — Mon, 21 Jun 2021 23:35:08 +0000

kudos for the heading.

Landlock (finally) sets sail

BruennPatrick — Mon, 21 Jun 2021 18:43:19 +0000

Did you mean unveil? To me landlock sounds like a combination of pledge [1] and unveil [2]
[1] https://man.openbsd.org/pledge.2
[2] https://man.openbsd.org/unveil.2

Landlock (finally) sets sail

l0kod — Mon, 21 Jun 2021 08:41:05 +0000

Landlock and Pledge (and XNU Sandbox, and Capsicum) have the same goal: to sandbox applications. Landlock is a bit more complex than Pledge because of the differences between a Linux distro (i.e. a set of eclectic software, including various kernels) and OpenBSD (i.e. roughly a monolithic set of compatible software, with a specific kernel). One of Pledge's strength is its simplicity, which is also a limitation. Landlock has a more flexible (and then more complex) kernel API than Pledge, but the idea is to rely on user space libraries to make the use of Landlock simple (e.g. the Pledge API could eventually be implemented with Landlock). This first release of Landlock targets basic file-system rights, which is the only objective of Pledge, but Landlock is designed to be able to support more fine-grained access-control types over time.

Landlock (finally) sets sail

ashkulz — Sun, 20 Jun 2021 11:44:18 +0000

Isn't this similar to pledge which was introduced in OpenBSD?