Linux Capabilities Revisited(dfir.ch)
dfir.ch
Linux Capabilities Revisited
https://dfir.ch/posts/linux_capabilities/
42 comments
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.
The setuid binaries already existed, and this was a means to making them (much) more secure without API changes.
The use of a fd for access to a file is one of the places where Linux follows a capability model. Not coincidentally, this is a part of the Linux API which is has not proven a good target for attacks.
I feel like it was around 10 to 15 years ago that some people were excited to eliminate all the setuid on various binaries in a linux distro, by using linux file xattr capabilities. And eventually it became apparent that this wasn't such a great scheme; many capabilities can be used to escalate to full root, basically. So, yeah, I think this is known. It takes some effort to find some good write-ups from back then, but here we go: https://lwn.net/Articles/632520/ https://forums.grsecurity.net/viewtopic.php?f=7&t=2522&sid=c...
If they're not passed around as objects a la FILE*/fd they're not even really capabilities, just (sparkling) fine-grained ambient authority (which still has value to be clear).
Ditto Solaris' privileges system (which is basically Linux capabilities done better, but still the same abstract model).
A shared global namespace ultimately makes it very difficult to have a decent capability based security system. Namespaces limited to the set of actions you have and a hierarchy of capabilities whereby children can only be given access to capabilities their parents have is required for a sane view of how things work. Much like encapsulation makes it easier to reason about abstractions in a program, this nested hierarchy of capabilities makes it easier to reason about the privilege of various parts of the system. Instead we have soup where no one can quite reason about what has access to what.
Note it is just a set of flags that subdivide the privileges root has which is potentially an improvement over what we had before but it's nothing like the real capability-based security
https://en.wikipedia.org/wiki/Capability-based_security
that you had in AS/400 or the iAPX 432 where a "capability" is a reference to a system object with associated privileges. It is possible to get this into a POSIX-like system
https://en.wikipedia.org/wiki/Capsicum_(Unix)
It reminds me of using a VAX-11/730 with the VMS operating system in high school where there was a long list of privileges a process could have
https://hunter.goatley.com/vax-professional-articles/vax-pro...
and it was a common game to investigate paths such as "if you have privilege A, B, and C you can get SETPRV and take over the machine"
https://en.wikipedia.org/wiki/Capability-based_security
that you had in AS/400 or the iAPX 432 where a "capability" is a reference to a system object with associated privileges. It is possible to get this into a POSIX-like system
https://en.wikipedia.org/wiki/Capsicum_(Unix)
It reminds me of using a VAX-11/730 with the VMS operating system in high school where there was a long list of privileges a process could have
https://hunter.goatley.com/vax-professional-articles/vax-pro...
and it was a common game to investigate paths such as "if you have privilege A, B, and C you can get SETPRV and take over the machine"
A very similar process happens in security research for macOS and iOS w/ the mach kernel. Researchers look for open mach ports that are ripe for privilege escalation.
In particular the big win with a true capability system is avoiding the confused deputy problem. True capability systems avoid it by always associating the action to be taken, with the reason why you should be able to take it. And so a deputy who acts on behalf of A and B, cannot accidentally take an action for A using a permission from B.
But Linux "capabilities" do not address this. If you have the permission, you have the permission. And can do the action. Even if the reason why you are trying to do the action (needed for A's request) doesn't match the reason that you are able do it (needed to do things for B).
But Linux "capabilities" do not address this. If you have the permission, you have the permission. And can do the action. Even if the reason why you are trying to do the action (needed for A's request) doesn't match the reason that you are able do it (needed to do things for B).
You can get there most of the way with SeL4 and CHERI.
Linux capabilities are fairly unrelated to the traditional concept of object capability based security.
They're closer to apple entitlements, but inherited through through forks rather than being attached to a binary.
They're closer to apple entitlements, but inherited through through forks rather than being attached to a binary.
Even if not super fine grained, I think that OpenBSD’s pledge is really nicely done.
Next after that I’d vote for FreeBSD’s capsicum.
Next after that I’d vote for FreeBSD’s capsicum.
I disagree. Pledge requires every app to OPT IN to security. This means that most apps won't do it, and the ones that do will likely be lazy and restrict their usage to what they use before and won't do the work of rearchitecting things.
So we shouldn't provide simple hardening tools because it won't be used or applied how you'd like in 100% of software? This mindset in security circles really needs to stop.
If a piece of important or foundational software wants to lock itself down today, look at the myriad of convoluted "solutions" mentioned in a sibling comment. If you wanted to discourage progress in this area, that's how you'd design something. I'm not assuming malice, obviously, but it's certainly a product of the endless nitpicking and "not good enough, doesn't cover <niche usecase>" type of thinking.
EDIT:
> and the ones that do will likely be lazy
I'd argue the opposite, any developer taking the time to add some pledge calls to their code is probably mindful of security and wants to improve it. If you wanted to be lazy, you'd just... not implement pledge at all since it'd get in your way and be too restrictive.
If a piece of important or foundational software wants to lock itself down today, look at the myriad of convoluted "solutions" mentioned in a sibling comment. If you wanted to discourage progress in this area, that's how you'd design something. I'm not assuming malice, obviously, but it's certainly a product of the endless nitpicking and "not good enough, doesn't cover <niche usecase>" type of thinking.
EDIT:
> and the ones that do will likely be lazy
I'd argue the opposite, any developer taking the time to add some pledge calls to their code is probably mindful of security and wants to improve it. If you wanted to be lazy, you'd just... not implement pledge at all since it'd get in your way and be too restrictive.
It's not that we shouldn't provide it, but it doesn't make sense invest into when OpenBSDs security is so far behind the rest of the industry. A program being able to steal your .ssh keys without you knows is unacceptable. Not only that but programs can keylog you, take pictures of what you are doing, or take remote control of your computer.
I doubt you could keylog my openbsd server that I remote into over ssh or serial.
I also doubt you can take pictures of me when it doesn't have cameras attached. If it did and you were to take pictures, you'd see some blinking leds and cables all day.
And I highly doubt you could take remote control even if I had openssh open to the public.
Perhaps your industry just doesn't care about the same things the openbsd community does.
Edit: I missed the ssh key stealing. My keys are always encrypted.
I also doubt you can take pictures of me when it doesn't have cameras attached. If it did and you were to take pictures, you'd see some blinking leds and cables all day.
And I highly doubt you could take remote control even if I had openssh open to the public.
Perhaps your industry just doesn't care about the same things the openbsd community does.
Edit: I missed the ssh key stealing. My keys are always encrypted.
Bash aliases and PATH aren't protected so malware can change ssh to something else and steal your encryption password to decrypt your keys.
Yeah but how does the malware get there?
It would be very powerful to get malware into ports and packages. It would also be noticed rather quickly. OpenBSD developers tend to run everything through dynamic tracers and other debugging tools.
It would be very powerful to get malware into ports and packages. It would also be noticed rather quickly. OpenBSD developers tend to run everything through dynamic tracers and other debugging tools.
The thing is, it works better. A simple API like pledge/unveil allows apps to significantly improve the security level without much of time investment.
Meanwhile, complex external systems like SELinux end up being unused because they are complex and external (and thus can just be ignored).
Meanwhile, complex external systems like SELinux end up being unused because they are complex and external (and thus can just be ignored).
>it works better
It doesn't. You can download malware and the app can cryptolock your entire system. Sure, if the malware called pledge to block opening files but what malware is going to do that?
It doesn't. You can download malware and the app can cryptolock your entire system. Sure, if the malware called pledge to block opening files but what malware is going to do that?
> Meanwhile, complex external systems like SELinux end up being unused because they are complex and external (and thus can just be ignored).
Wdym? It's very notably used in Android
Wdym? It's very notably used in Android
Yeah, because they have a team of engineers working on it. They can afford that.
I have never seen SELinux used on a regular server. Heck, Amazon Linux AMIs on AWS even disable it by default.
Yeah, yeah, personal experience and all that.
I have never seen SELinux used on a regular server. Heck, Amazon Linux AMIs on AWS even disable it by default.
Yeah, yeah, personal experience and all that.
This has changed a lot in the past decade -- any modern Fedora box has SELinux enabled by default now and so I would wager the majority of Fedora/CentOS/AlmaLinux/RHEL boxes have SELinux enabled and in enforcing mode. openSUSE/SLES is also switching to SELinux in 16.0.
Disclaimer: I work for SUSE.
Disclaimer: I work for SUSE.
Sure, it won't be used a lot, but some applications will. Including application that lets you wrap any other application like https://wiki.alpinelinux.org/wiki/Bubblewrap
Tools like SELinux allow administrators to restrict a program before it runs, a sort of guard rail.
pledge() allows developers to further restrict a program dynamically at runtime. More like defensive driving.
Both are useful techniques.
pledge() allows developers to further restrict a program dynamically at runtime. More like defensive driving.
Both are useful techniques.
OpenBSDs pledge is so simple and nice to use. I really wish Linux would incorporate it. Seccomp is a nightmare to implement.
There is a port...
https://github.com/jart/pledge
https://justine.lol/pledge/That uses seccomp under the hood and requires a custom libc, I think?
Definitely a nice project, but I don't know if I'd use it in production.
Definitely a nice project, but I don't know if I'd use it in production.
I'd rather have a simple coarse-grained mechanism than whatever feverdream that seccomp, selinux and apparmor are. A convoluted mess incorporating almost Turing complete languages that are just asking to shoot yourself in the foot a mile deep.
The simplicity of pledge is good enough for 99% of use-cases I'd wager AND easy to add to existing code.
The simplicity of pledge is good enough for 99% of use-cases I'd wager AND easy to add to existing code.
> whereby children can only be given access to capabilities their parents have
The one thing that makes capabilities usable is that they don't need to follow that rule.
If you don't have processes that let your programs get capabilities from any source other than their creation, you are better just adding your program names into your ACLs.
The one thing that makes capabilities usable is that they don't need to follow that rule.
If you don't have processes that let your programs get capabilities from any source other than their creation, you are better just adding your program names into your ACLs.
I don't think you can bolt something like what you're describing onto an existing kernel (like linux did with capabilities). You'd have to design it this way from the ground up. I think I've read about some experimental OSs exploring that kind of capability by design, almost like a type 1 hypervisor but for processes.
Fuchsia pervasively uses capabilities.
Note that namespaces are effectively capabilities.
One problem that I have with fine-grained ACLs is that they can unintentionally add security risk, because sometimes those finer grained controls can be exploited to gain additional privledges.
If I grant something root, I know what that means and I'll be very careful. But if I grant something permission X thinking I'm safe, and then it can be used to gain permission Y, or even root, then I can be accidentally exposed.
There is just a much larger surface area to guard against, ensuring that each granular permission can't be so exploited.
If I grant something root, I know what that means and I'll be very careful. But if I grant something permission X thinking I'm safe, and then it can be used to gain permission Y, or even root, then I can be accidentally exposed.
There is just a much larger surface area to guard against, ensuring that each granular permission can't be so exploited.
It's all a challenge whether you have fine-grained permissions or coarse-grained permissions.
With coarse-grained permissions you end up needing proxies, which is nice because you can do whatever you want in terms of business logic, but also very much not nice because you have to write the proxies and the client code to talk to them, and then you have to keep maintaining and extending them.
Either way you have to do audits and static analysis looking for escalation vectors, and that's strictly harder -but not insurmountable- with fine-grained permissions.
So I think fine-grained permissions win.
I've implemented (and I'm trying to get approval to publish a paper on) a cross between RBAC-style and SMACK-style labeled security (where the labels are literal human-readable strings, not MLS-style bitmaps + levels) for application-level authorization, but it's very fast and should work in-kernel too if anyone wanted to make it work there. This system lets you have authorization as fine- or coarse-grained as you want by using many distinct labels (fine-grained) or few labels (coarse-grained) to label the application (or kernel) objects with.
With coarse-grained permissions you end up needing proxies, which is nice because you can do whatever you want in terms of business logic, but also very much not nice because you have to write the proxies and the client code to talk to them, and then you have to keep maintaining and extending them.
Either way you have to do audits and static analysis looking for escalation vectors, and that's strictly harder -but not insurmountable- with fine-grained permissions.
So I think fine-grained permissions win.
I've implemented (and I'm trying to get approval to publish a paper on) a cross between RBAC-style and SMACK-style labeled security (where the labels are literal human-readable strings, not MLS-style bitmaps + levels) for application-level authorization, but it's very fast and should work in-kernel too if anyone wanted to make it work there. This system lets you have authorization as fine- or coarse-grained as you want by using many distinct labels (fine-grained) or few labels (coarse-grained) to label the application (or kernel) objects with.
Just got the final approval. I need to make a better home for this, like a proper GH repo and a submission to the arxiv, but here it is: https://gist.githubusercontent.com/nicowilliams/c812b7354f69...
For this to work, Linux needs a centralized way of managing caps. Review (or diff) the file and know immediately what's changed, instead of looking at ACLs all over the place.
Traditional unix /etc/group style.
Traditional unix /etc/group style.
Linux capabilities have a hook in the Linux Security Module (LSM) system, so you can write an LSM module to do whatever centralized management system you want.
The only LSM I have much experience is SELinux, which capabilities directly as SELinux permissions. I imagine most other general purpose LSMs do simmilar.
I could imagine an LSM that implements a policy of allowing capabilties based on UID/GID; although I'm not aware of any current LSMs that do that.
The only LSM I have much experience is SELinux, which capabilities directly as SELinux permissions. I imagine most other general purpose LSMs do simmilar.
I could imagine an LSM that implements a policy of allowing capabilties based on UID/GID; although I'm not aware of any current LSMs that do that.
And why does it have to be that complicated? Why can't we just
echo "CAP_KILL CAP_SYS_NICE /usr/bin/htop" >> /proc/sys/kernel/some_file
echo "CAP_FOWNER CAP_CHOWN /usr/bin/mc" >> /proc/sys/kernel/some_file
cp /etc/caps /proc/sys/kernel/caps
That's totally true, you actually have examples of unsafe capabilities delegation in the other article mentioned in the References: https://juggernaut-sec.com/capabilities/
Fascinating, thank you for sharing.
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.