←back to thread

190 points Harvesterify | 1 comments | | HN request time: 0.208s | source
Show context
WhyNotHugo ◴[] No.45673859[source]
I find Linux’s approach on capabilities underwhelming, and not even close to a true capability-based system.

For example, you can pass a program a capability to bind any privileged port, but not a specific one. For this scenario, just passing an fd bound to the port is actually much simpler and safer. For other capabilities, they’re just too coarse.

The fact that capabilities are implicitly inherited also doesn’t sound like a good approach on security. It’s likely like this due to backward compatibility, but I really think that capabilities ought to be passed explicitly, and we should be able to transfer them between processes. In fact, using an fd as a handle for capabilities would probably be a much clearer and explicit approach.

replies(4): >>45674780 #>>45676466 #>>45676774 #>>45678086 #
1. ajross ◴[] No.45676774[source]
This is misunderstanding what the feature is for. The point wasn't to architect a "capabilities-based system" from scratch (see LSM/selinux/apparmor for work in that space). It was to split up the very practical set of "things setuid is traditionally used for" into finer chunks.

The setuid binaries already existed, and this was a means to making them (much) more secure without API changes.