The need to drop privileges at all is a natural consequence of a process spawning API with inherit-by-default capability semantics. You'd never build a new VM or OS this way if you didn't require compatibility with existing software. The secure solution has always been default-nothing semantics, with whitelisted capabilities granted via explicit arguments in the process spawning API.
The closest you can get to that model on Linux is the strict mode in seccomp, which disallows every syscall except read(), write(), exit() and sigreturn(). It's more or less a way to restrict a process to being "pure compute/memory". If the process then wants to poke and prod at the outside world, it can only do so by reading/writing the file descriptors it inherited prior to the seccomp call. You can build a RPC on top of that to emulate the "whitelist", with access control and restrictions/policies enforced by whatever is listening on the other end.
People have tried to build the opposite. It doesn't work well. Except in very limited cases you always end up passing every privilege or a god privilege to make it practical.
Sure, you can't avoid poorly designed apps. But a poorly designed app is much easier to fix/replace than a poorly designed OS, particularly when it comes to open-source software.
10000truths · · focus · HN ↗
The closest you can get to that model on Linux is the strict mode in seccomp, which disallows every syscall except read(), write(), exit() and sigreturn(). It's more or less a way to restrict a process to being "pure compute/memory". If the process then wants to poke and prod at the outside world, it can only do so by reading/writing the file descriptors it inherited prior to the seccomp call. You can build a RPC on top of that to emulate the "whitelist", with access control and restrictions/policies enforced by whatever is listening on the other end.
mitxela · · focus · HN ↗
10000truths · · focus · HN ↗