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.
Quoth the summary:
``POSIX file capabilities, which have recently become available in the Linux kernel; they are expected in the mainline kernel by 2.6.24.''
Recently become available? Haven't POSIX capabilities been in Linux for some time? I seem to recall reading about them in the documentation for some 2.4 kernel, and there is a Gentoo page about them from some time in 2005. Am I missing something?
Please correct me if I got my facts wrong.
RBAC has been in Linux for a long time, in the form of SELinux. The new thing is that you can store the privileges in the file system. The advantage is that you don't need to modify your formerly set-uid applications, so it is easier on the system administrator. The disadvantage is that you don't need to modify your applications, so any security vulnerabilities caused by running with a lower privilege (yes, that is possible) might not be discovered by the good guys first.
Finally! A year of moderation! Ready for 2019?
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
libguestfs - tools for accessing and modifying virtual machine disk images
>Well, the article is about capabilities, not ACLs, and Linux has had ACLs in the
>filesystem for years too.
Years yes... but they are still fairly new compared to the ACLs that are present in NTFS. Also, ACL's aren't really universal or standardized in linux. 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.
Which goes to your other point about people not using ACLs in Linux often. This is largely a cultural thing left over from unix, which discarded ACLs in order to save space on the file system, which is now a non issue.
>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.
You're saying that probably because you've only used single user Linux systems... which kind of defeats the purpose of unix as a multiuser operating system btw. ACLs provide a very important level of expressiveness on a multiuser system.
If user A wants to share files with user B, but no one else (say user A has an SVN repository) without ACL's a special group has to be created and A and B are added as members. This means that something as simple as giving someone else access to your files requires elevation to root! On a large multiuser system, very few users have root access, so it is usually simply impossible. Being able to add an ACL to your file that says "allow user A" solves the problem elegantly.
Linux ACL's have taken a while to arrive and mature, but I've used them a number of times to solve the problem above and I'm glad they are finally here and hope for more consistent support in the future. When you don't need ACL's, they may seem like unnecessary complexity. In that case, feel free to ignore them and use the traditional user/group/other permissions. When you need them though, you will be very glad they are there. Generally, if you really need to do something with ACL's and you try to emulate it with groups, you are likely to open security holes, or make your system unusable for some class of users you didn't think of. ACL's are not the simple solution to the problem, but they are often the only correct solution, which matters a lot to some people.
Windows does have the same concepts but it pales in comparison. Capabilities on Windows are purpose built rather than generic capabilities which further limits its value on Windows.
Windows had this functionality since day one. Lookup AdjustTokenPrivileges() on MSDN
Actually it does have similar mechanisms, in a way. Every process has a security token that determines what the process can and can't do. The main problem is that Windows doesn't really expose a good way to alter these permissions when the program is launched - it picks up whatever rights and permissions the user has. Runas is a good way around this, but there is no fundamental reason Windows couldn't let you right-click an exe, go to a permissions tab, and uncheck various permissions... like communicating over the network.
Natural != (nontoxic || beneficial)
Years ago, we swiped the idea from SGI's Irix. They seem to have swiped it from Data General's DG-UX.
We implemented everything but the filesystem support. Filesystem support is complicated. It's actually SE Linux that has driven our ability to put arbitrary security markings on files, along with non-security desires for various extended attribute and multi-fork things.
Unfortunately the set of bits was nearly copied from SGI's Irix, where it was botched. The bit choice is inflexible, redundant, and rather small. See, there's this "admin" bit that controls nearly everything...
SGI also botched the math. Well, to excuse them a bit, the POSIX draft (never ratified) went through dramatic changes to the equations a few times.
Really we ought to rip out the trash and clone what Sun has, but that is terribly hard for compatibility. Some programs already deal with the capabilitites. For example, I think sendmail drops capability bits.
Be afraid of complexity junkies where security is involved.
I've used and supported both Windoze and Unix systems and find that the more complex file permissions are the more likely they are to be simply turned off. The Current Linux system works well enough and users can understand it well enough. These other fixes will only create 10 times the problems they claim to fix.
Yes, CAP_NET_BIND_SERVICE is a distinct capability. See "man capabilities" on a Linux box, although you may also want to give it CAP_SYS_CHROOT ... depending on how paranoid you are.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B