Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Capabilities Revisited

dfir.ch

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Linux Capabilities Revisited

#31

Post by btilly »

PaulHoule wrote: post #4
surajrmal wrote: post #2

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 hierar…

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 htt…

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).

Re: Linux Capabilities Revisited

#32

Post by btilly »

WhyNotHugo wrote: post #24

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 sou…

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.

Re: Linux Capabilities Revisited

#33

Post by 0x457 »

charcircuit wrote: post #11
rootnod3 wrote: post #3

Earlier quoted context omitted.

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.

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.

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

Re: Linux Capabilities Revisited

#34

Post by qu4z-2 »

WhyNotHugo wrote: post #24

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 sou…

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).

Re: Linux Capabilities Revisited

#35

Post by ajross »

WhyNotHugo wrote: post #24

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 sou…

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.

Re: Linux Capabilities Revisited

#36

Post by charcircuit »

munchlax wrote: post #29
charcircuit wrote: post #26

Earlier quoted context omitted.

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 com…

Bash aliases and PATH aren't protected so malware can change ssh to something else and steal your encryption password to decrypt your keys.

Re: Linux Capabilities Revisited

#37

Post by ploxiln »

WhyNotHugo wrote: post #24

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 sou…

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...

Re: Linux Capabilities Revisited

#38

Post by cryptonector »

cryptonector wrote: post #23
Nifty3929 wrote: post #15

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 expose…

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…

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...

Re: Linux Capabilities Revisited

#39

Post by Harvesterify »

Nifty3929 wrote: post #15

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 expose…

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/

Re: Linux Capabilities Revisited

#40

Post by M95D »

gizmo686 wrote: post #20
M95D wrote: post #16

Earlier quoted context omitted.

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.

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 no…

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
or simply

  cp /etc/caps /proc/sys/kernel/caps
to apply all of them at once?
Post reply on HN