The stuff you can do with SELinux or LSMs is not stuff that makes sense to do.
Conversation
Then you give up on being able to filter access to kernel APIs like procfs, sysfs, debugfs, perf events, driver ioctls, etc. along with enforcing the security model between the sandboxes via static policy instead of only being something derived dynamically at runtime from code.
2
The upstream kernel has even rejected having a way to fully disable access to perf events without using an LSM. If you can do it with an LSM, they won't accept security features for it anymore. SELinux is even how you do restrictions on dynamic native code generation, etc.
1
1
Restrictions on dynamic native code generation is not a security boundary it's a walled garden market control boundary.
1
And perf events? Seccomp trivially blocks all access.
1
A problem with that is that you can't undo making the seccomp filter to do debugging/profiling without spawning the application again.
Due to the design of the system call API, you can't really do anything more than disallowing it as a whole. Can't allow a small portion of it.
2
1
Granularity of seccomp-bpf is based on system calls and integer parameters. Look at how the io_uring kernel API is set up as another example. If you don't fully disallow it, it bypasses an ever increasing amount of seccomp-bpf filtering since it's blind to what's behind pointers.
2
1
2
Landlock LSM (kernel.org/doc/html/lates) is meant to be the solution to seccomp-bpf being too crippled as a way to do self-sandboxing. I don't think they'll be receptive to seccomp-bpf needs in how they design system calls. Just look at what they did with io_uring already.
1
3
Landlock looks promising (a first for LSMs) but largely unneeded IMO. Namespaces + seccomp pretty much fully suffice. Seccomp to block all newfangled syscalls and trace/debug type stuff, and ns's for virtualizing resources.
1
For the most part namespaces don't restrict what processes do. They gain capabilities via the kernel and other processes via file descriptors.
Mount namespaces give them their own path hierarchy but don't sandbox their filesystem access. Similar for most other than userns.
2
So, for example, for Flatpak, they've done everything based around IPC via dbus. The security policy is spread out across the kernel and a bunch of userspace processes including other applications. It's not spelled out clearly. Android uses SELinux to statically define policies.