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

21–30 of 43 posts

Re: Linux Capabilities Revisited

#21

Post by shwaj »

candiddevmike wrote: post #10
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…

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.

Re: Linux Capabilities Revisited

#22

Post by FuriouslyAdrift »

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…

You can get there most of the way with SeL4 and CHERI.

Re: Linux Capabilities Revisited

#23

Post by cryptonector »

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

Re: Linux Capabilities Revisited

#24

Post by WhyNotHugo »

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.

Re: Linux Capabilities Revisited

#25

Post by charcircuit »

cyberax wrote: post #14
charcircuit wrote: post #11

Earlier quoted context omitted.

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.

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

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

Re: Linux Capabilities Revisited

#26

Post by charcircuit »

hypeatei wrote: post #12
charcircuit wrote: post #11

Earlier quoted context omitted.

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…

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.

Re: Linux Capabilities Revisited

#27

Post by ori_b »

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 that namespaces are effectively capabilities.

Re: Linux Capabilities Revisited

#28

Post by lagosfractal42 »

cyberax wrote: post #14
charcircuit wrote: post #11

Earlier quoted context omitted.

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.

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

Wdym? It's very notably used in Android

Re: Linux Capabilities Revisited

#29

Post by munchlax »

charcircuit wrote: post #26
hypeatei wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: Linux Capabilities Revisited

#30

Post by cyberax »

lagosfractal42 wrote: post #28
cyberax wrote: post #14

Earlier quoted context omitted.

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

Post reply on HN