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

11–20 of 43 posts

Re: Linux Capabilities Revisited

#11

Post by charcircuit »

rootnod3 wrote: post #3
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…

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.

Re: Linux Capabilities Revisited

#12

Post by hypeatei »

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.

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

Re: Linux Capabilities Revisited

#13

Post by marcosdumay »

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…

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

Re: Linux Capabilities Revisited

#14

Post by cyberax »

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.

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

Re: Linux Capabilities Revisited

#15

Post by Nifty3929 »

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.

Re: Linux Capabilities Revisited

#16

Post by M95D »

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…

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.

Re: Linux Capabilities Revisited

#17

Post by eikenberry »

hypeatei wrote: post #6
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.

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/

Re: Linux Capabilities Revisited

#18

Post by elevation »

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.

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.

Re: Linux Capabilities Revisited

#19

Post by hypeatei »

eikenberry wrote: post #17
hypeatei wrote: post #6

Earlier quoted context omitted.

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.

Re: Linux Capabilities Revisited

#20

Post by gizmo686 »

M95D wrote: post #16
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…

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 not aware of any current LSMs that do that.

Post reply on HN