←back to thread

Linux Capabilities Revisited

(dfir.ch)
190 points Harvesterify | 2 comments | 22 Oct 25 13:50 UTC | HN request time: 0s | source
Show context
Nifty3929 ◴[22 Oct 25 16:45 UTC] No.45671784[source]▶
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.

replies(3): >>45671971 #>>45673720 #>>45679347 #
1. M95D ◴[22 Oct 25 16:56 UTC] No.45671971[source]▶
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.

replies(1): >>45672892 #
2. gizmo686 ◴[22 Oct 25 18:04 UTC] No.45672892[source]▶
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.