Restrictions on dynamic native code generation is not a security boundary it's a walled garden market control boundary.
Conversation
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
Gain capabilities? That's not a thing unless you botched the basics (nosuid).
1
In a user namespace, you can't gain any new capabilities outside of your user namespace. User namespaces are where all the most important stuff happens.
2
I'm talking about capabilities in the security sense rather than 'POSIX' capabilities.
1
For example, Android has a service with the low-level read-only and runtime system properties. The rules for accessing that are statically defined via SELinux policy. The low-level rules for accessing services are also defined that way. It's just a static form of security policy.
But my rule for accessing services is far more secure: you don't get to. At all.
1
Okay, so now make it so that you can run an app that needs OpenGL, audio, printing and a whole bunch of other things. Those are going to involve communication with OS services. There's a whole user-facing UI for the user to authorize things and services implementing all that.
1
Show replies
The point of it is that it's static and unchanging at runtime so you can analyze and improve baseline security policy in a declarative way. You can add enforcement to something and then write declarative, static policies for that. It's just a tool for writing those policies.