Mastering POSIX File Capabilities

An anonymous reader passes along an IBM DeveloperWorks article on POSIX file capabilities, which have recently become available in the Linux kernel; they are expected in the mainline kernel by 2.6.24. POSIX file capabilities parcel out root user powers into smaller privileges. The article details how to program using file capabilities and how to switch on the ability of a system's setuid root binaries to use file capabilities.

Comments

Re:At last

[Anonymous Coward]

Nope, I don't think you read and/or understood the article. This has nothing to do with file permissions it affects what 'capabilities' the resulting process has when it is executed. As far as I know Windows does not have anything similar. As for NTFS style ACLs those have been around for a while, google for POSIX ACLs.

Not the correct comparison.

[Junta]

Linux has had filesystem ACLs for ages (arbitrary lists of people with sets of permissions above and beyond user/group/world permissions).

This is essentially a finer-grained setuid. I.e., before, the filesystem permission granularity was 'the /bin/ping program code is permitted to assume root privileges', because ping needed to do *one* thing that only root could do. Code in this position is generally thoroughly audited and such, but presume for a moment a user figured out a buffer overflow using some ICMP pattern that would cause ping to execute arbitrary code. If not written correctly, the results could be disasterous. If well written, the program code has dropped all but the capability it needed, but the kernel/permissions aren't forcing the issue so the code must be trusted.

Enter this mechanism. Now, you can *force* the issue in the filesystem permissions to never even possibly allow ping anything but what it needed. If ping was badly written to not drop any privileges, and a malicious user overflowed, he'd still only be able to create raw sockets, and nothing more.

This sort of complexity I'm not sure is dealt with in Windows (or how) I don't even know what may or may not need setuid to be a good example under their architecture. It certainly paves the way for future distributions to have a lot fewer setuid programs to worry about (though, on the flip side, programs with few enhanced capabilities may still be dangerous and yet be less obvious as it isn't setuid, file listing may have to be tweaked to reflect the kinda-setuid nature to leave awareness).

Re:Recently become available?

[Junta]

POSIX capabilities are old, the ability to store which capabilities are permitted just like ACLs/owner/permission is new.

So before, ping gets executed and it's up to ping code to assume/give up unneeded POSIX capabilities as permitted by the rather broad setuid bit. Now, it's execed only with the appropriate capabilities even being possible, without needing the rather broad setuid bit being set. Setuid can be safe with effort, but if the program can operate under a more specific security context, all the better.

OT: ACLs

[Richard W.M. Jones]

Well, the article is about capabilities, not ACLs, and Linux has had ACLs in the filesystem for years too.

To get to the point though: Administrators don't use ACLs on Linux because they make file permissions much harder to understand, for what is in reality an unimportant increase in expressiveness. Simple user/other permissions are easy to understand and work 99% of the time, groups fill in another few cases (eg. permissions on shared sockets), and ACLs are almost never necessary.

SELinux is another "interesting" area. Since I started to use Fedora again, I really wanted to use SELinux. I really did. But because I'm always using Rawhide (the bleeding-edge development version) I've had to turn SELinux off. It's too complex to understand and breaks too often on Rawhide. I'd only recommend it on a stable version (eg. RHEL/Centos) and then just as a final line of defense security measure, not to implement ACLs.

Rich

I mastered them...

[m2943]

by not using them. They are some holdover from a time when people thought that VMS was so much better than UNIX because it had so many more features.

The first principle of security is KISS, and they violate this principle big time.

Unfortunately...

[Junta]

ls is not equipped (as far as I know) for displaying acls.

$ getfacl .
# file: .
# owner: ownaccount
# group: owngroup
user::rwx
group::r-x
other::r-x

That was default, reflecting:
drwxr-xr-x 2 ownaccount owngroup 4096 2007-12-23 12:28 .

$ setfacl -m mythtv:rw .
$ getfacl .
# file: .
# owner: ownaccount
# group: owngroup
user::rwx
user:mythtv:rw-
group::r-x
mask::rwx
other::r-x

And ls shows:
drwxrwxr-x+ 2 ownuser owngroup 4096 2007-12-23 12:28 .

Note the +. It's enough to indicate acl existance, but not more than that.