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`.
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 :)
> 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.
I'd love to see a comparison of landlock to restricted containers.