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.
This is IMHO one of the very few areas where Windows has had an advantage over Linux. NTFS ACLs have been this granular since, what, 1993?
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
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.
Wow, they've invented a neutered version of RBAC.
way to be innovative.
How do POSIX capabilities compare to systrace?
Please correct me if I got my facts wrong.
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.
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.
AFAIR the default in windows (at least up to vista) was to make EVERYTHING "setuid root", even child games would require root access to RUN (as opposed to installation)
What a misleading article. There are some technical details that are new, but capabilities are extremely old and have been available for Linux for almost a decade. They haven't seen much use, and that's the part that might change, but filing this as a new development is stupid. It'll only invite the windos shills to claim that windos is so much better because they've had granular permissions for sooo long (yes, they had, for about the same time Linux did. same story, almost nobody uses them.)
Assorted stuff I do sometimes: Lemuria.org
>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.
Seeing as how you can make an unprivileged account and those programs are prevented from doing this or that. It's just that all recommendations/forums/etc/etc have *always* said 'always run as an administrator account' because Windows applications as a rule may not be well designed for a well secured environment.
If *everything* was setuid, it wouldn't matter whether you had administrator privilege or not. Also, runas wouldn't be needed for privilege escalation.
XML is like violence. If it doesn't solve the problem, use more.
http://www.gentoo.org/proj/en/hardened/ (other ways to harden your system are available)
wor
stack smashing
Transparent implementation of PaX address space layout randomizations and stack smashing protections using ELF shared objects as executables.
also regading acl
RSBAC is Mandatory Access Control security system based on the GFAC framework logic. It includes standard models, like the Role Compatibility, Access Control Lists and Mandatory Access Control. RSBAC enforces access control rules on your operating system.
however AFAIK this stuff is only used by super admins because its the oposite of the 10% rule its 90% of the work to get 10% of the protection.
Windows had this functionality since day one. Lookup AdjustTokenPrivileges() on MSDN
With my parents using Ubuntu, I must say this:
I hope that by 2008 the desktop will be ready for GNU/Linux.
You can't handle the truth.
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.
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.
Lots of programs try to limit themselves when run as setuid root. For example, they refuse some kind of user input. If they see that they are NOT running setuid root, then they assume that they have no privilage and that thus there is no need to limit themselves.
Other programs assume that if ONE privileged operation succeeds, then some OTHER privileged operation will also succeed. (because root can traditionally do everything) When that other operation fails unexpectedly, you may get some sort of inconsistant state. Inconsistant state is the playground of an attacker.
With this new feature, both sorts of sloppy programming become security holes.
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
It's better than the alternative of all-out access. That's why only one security mechanism isn't enough. In your case, if they managed to exploit ping for raw socket access to arp spoof, they could launch a DoS or start a man-in-the-middle attack. Not much can be done with the DoS, but SSL and ssh protocols should guard against the man-in-the-middle if used correctly.
The point is every facility needs to do it's part to mitigate risk security wise. It may be better to provide a facility to do ICMP echo request and forward replies without administrator privilege somehow (if ICMP weren't designed the way it is, it probably would have existed long ago), but this was merely an easy-to-follow example of risk mitigation through restricted capabilities, showing a reduced exposure over the previous practice, not an eliminated exposure..
XML is like violence. If it doesn't solve the problem, use more.