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

[cryptonector]

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.

[cryptonector]

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

[M95D]

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.

[gizmo686]

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.

[M95D]

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?

[Harvesterify]

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/