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.
Yes. Now in a year or so, Linux will be ready for the desktop. 2008 is the year of Linux on the desktop!
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
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.
>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.
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
Windows had this functionality since day one. Lookup AdjustTokenPrivileges() on MSDN
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.
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.
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