staticassertion 3 days ago

> I'd love to see a comparison of landlock to restricted containers.

One thing to consider is that containers virtualize. You enter new "namespaces" where you aren't necessarily restricted within that namespace, but the namespace as a whole is sort of your own playground. So a PID namespace only allows you to see other processes within that namespace.

This is very distinct from a resource oriented approach like landlock. Landlock may allow you to say "you can do certain actions to certain processes" but you wouldn't get the same semantics as "I can only see specific processes to begin with". They would layer nicely.

Similarly, containers provide virtualized file systems. A write happens in a container and it's allowed, but the write is isolated from the host. Landlock would instead allow or deny that write.

They go very well together.

razighter777 4 days ago

Comparing landlock to containers isn't really an apples to apples comparison. Containers use a bunch of linux security mechanisms together like chroot seccomp and user namespaces to accomplish their goals. Landlock is just another building block that devs can use.

Fun fact: because landlock is unprivleged, you can even use it inside containers; or to build an unprivileged container runtime :)

vaylian 3 days ago

seccomp is for restricting syscalls to the kernel. But because "everything is a file" on UNIX systems, you can do a lot of good and bad things just with `open`, `openat`, `read` and `write`.

  • PeterWhittaker 3 days ago

    Of course, but you can also restrict those operations. The seccomp whitelist library I wrote only sealed itself after all FDs were opened for specific operations, and the API didn't expose the calls directly. Once sealed, the app got only those operations now specifically allowed.