Slashdot Mirror
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.
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.
Linux has had filesystem ACLs for ages (arbitrary lists of people with sets of permissions above and beyond user/group/world permissions).
/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.
This is essentially a finer-grained setuid. I.e., before, the filesystem permission granularity was 'the
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).
XML is like violence. If it doesn't solve the problem, use more.
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.
XML is like violence. If it doesn't solve the problem, use more.
Since the so called sendmail capabilities bug there was no broad use of capabilities. But inside the kernel, capabilities "survived". If a process was asking for a privileged action like opening a privileged port, the process was checked for having the needed capability. As there was no way to grant a process a distinct capability the only way was to start this process in the context of root, who has by definition all capabilities. Now its possible to give the binary the extended attribute capability and if so the resulting process is checked whether it has the needed capability (which is stored inside the xattr capability). Now you don't have to trust the program to reduce its set of capabilities, you can start it with and only with the needed capabilities. So if ping goes wild, it can only open more ports but not - lets say - change your /etc/passwd. Now, there is a mean to eliminate root-owned suid-bit binaries. For examples have a look at my documentation: http://www.friedhoff.org/fscaps.html
SELinux provides ACLs, as does AppArmor, which suze uses. It's kind of hard to adopt a permissions system that works differently between distros and not at all on some.
Neither SELinux nor AppArmor provides ACLs. ACLs are discretionary access controls, users can change the permissions. SELinux and AppArmor provide mandatory access control.
ACLs have been in the Linux file systems for ages, and they work exactly the same across distributions. They just aren't used.
Finally! A year of moderation! Ready for 2019?
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.
XML is like violence. If it doesn't solve the problem, use more.
Does this mean that I'll finally be able to allow servers to bind to port 80, without having to run the whole thing as root? Please?
Apache does pretty well with "downgrading" its running privileges, but many others, not so much.
sic transit gloria mundi