4 ms·

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 o

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.

nine_k 5d ago
Fundamentally, Unix security is per user (in uid sense), identity-based with ambient authority, not capability-based with directly passed authority. There are many attempts to nerf, limit, lock down authority at the process level, but they all go against the initial architectural grain. Unix was not designed to protect users from themselves, only from each other.
int0x29 5d ago
By default when creating a new thread or process under Fuchsia you don't have access to the kernel. You have to create the thread or process with explicit kernel access. Pity Fuchsia kinda got killed off (Ok its not completely dead yet but its slowed a lot. There still doesn't seem to be a 2026 roadmap either)
mitxela 5d ago
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.
- 10000truths 5d ago
  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.
Levitating 5d ago
Are there any operating systems that work like this?

nine_k 5d ago

Fundamentally, Unix security is per user (in uid sense), identity-based with ambient authority, not capability-based with directly passed authority. There are many attempts to nerf, limit, lock down authority at the process level, but they all go against the initial architectural grain. Unix was not designed to protect users from themselves, only from each other.

int0x29 5d ago

By default when creating a new thread or process under Fuchsia you don't have access to the kernel. You have to create the thread or process with explicit kernel access. Pity Fuchsia kinda got killed off (Ok its not completely dead yet but its slowed a lot. There still doesn't seem to be a 2026 roadmap either)

mitxela 5d ago

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.

10000truths 5d ago
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.

Levitating 5d ago

Are there any operating systems that work like this?