Slashdot Log In
Mastering POSIX File Capabilities
Posted by
kdawson
on Sun Dec 23, 2007 02:54 AM
from the wee-dram-of-privilege dept.
from the wee-dram-of-privilege dept.
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.
Related Stories
Submission: POSIX capabilities: Parceling the power of root by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
RBAC, Anyone? (Score:2)
way to be innovative.
Re: (Score:3, Interesting)
nope, we "invented" prior to Sun (Score:3, Interesting)
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 sm
Systrace? (Score:2)
Recently become available? (Score:3, Interesting)
``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?
Re: (Score:2)
#define _LINUX_CAPABILITY_VERSION 0x19980330
This suggests to me that Linux has had capabilities since 1998 at least...
Re:Recently become available? (Score:4, Funny)
Parent
Re:Recently become available? (Score:5, Informative)
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.
Parent
Re: (Score:3, Interesting)
What is new is not that Linux has POSIX capabilities.
What is new is that you can store a description of the capabilities an executable is to receive _on the executable_.
Re: (Score:3, Insightful)
Linux having full POSIX capabilities is good, but frankly there are getting to be too many wholly independent security mechanisms. That's not to say that a single system woul
Re: (Score:2)
If you want to get a bit more paranoid, the sorts of companies using hi
I mastered them... (Score:5, Insightful)
The first principle of security is KISS, and they violate this principle big time.
Re: (Score:2, Insightful)
right, this actually adds holes (Score:2)
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 inconsista
Re: (Score:2)
Sloppy programming is security holes.
Assuming the implemenation works fine, then if an app is making the assumption that because it can do X then it can do Y, well, it will find out that it really cannot do Y, and it'll get killed. Then you can fix it. Ah, the tragedy!
Re: (Score:2)
Suppose the app takes a lock (or similar) which requires privilege. This succeeds. The app then does something else which requires privilage, and fails.
If the app dies at this point, things are stuck. Hopefully a reboot can clear the problem. Depending on the nature of the app, you may well have database corruption.
BTW, maybe I shouldn't have referred to the first case as sloppy programming. It's perfectly legit on a traditional system that lacks the
Re: (Score:2)
A system that relies on the administrator being a security guru probably isn't that secure in the real world where most administrators don't have time to become security experts...
Re: (Score:2)
old news (Score:2)
Re: (Score:2)
> extremely old and have been available for Linux for almost a decade.
I don't think so. Process capabilities are there for a long time, but file capabilities has not been there (in other words, there is no file system that support letting users to set programs to be "setuid 0, but only allow sending signals to arbitrary processes, without any other special ability of the root user"). Without file capabilities, only programmers can
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Doesn't it sound barkingly insane to say "run as a God User except only able to do X, Y, and Z?" Why indeed even have root in the first place? But that's still what these capabilities are -- set a single set of bits in a process (to all zeros no less) and let it do everything, THEN strip out what
More complexity = less security (Score:3, Interesting)
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.
Re: (Score:2)
Be afraid of complexity junkies where security is involved.
I don't think that the OpenBSD folks [openbsd.org] are complexity junkies. OK, I'm not really up on all this stuff, but I think I get the gist of their thinking. Here's what I believe the pro-capabilities people would tell you:
You're advocating a false economy. Sure, capabilities are potentially complex and the implementation is hard to get right. Still, you only have to do it right one time and everything else benefits. In today's situation, we have things like "ping" running setuid root so that it can create r
Too much to hope for? (Score:3, Informative)
Apache does pretty well with "downgrading" its running privileges, but many others, not so much.
Re: (Score:3, Interesting)
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.
Re:At last (Score:5, Informative)
Parent
Win32 AdjustTokenPrivileges (Score:2, Interesting)
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Not the correct comparison. (Score:5, Informative)
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).
Parent
Re: (Score:2)
Linux has had filesystem ACLs for ages (arbitrary lists of people with sets of permissions above and beyond user/group/world permissions).
News to me... ~ $ ls -l /etc
total 1302
-rw-r--r-- 1 root root 15069 Feb 24 2006 a2ps.cfg
-rw-r--r-- 1 root root 2563 Feb 24 2006 a2ps-site.cfg
drwxr-xr-x 4 root root 1024 Feb 19 2007 acpi/
-rw-r--r-- 1 root root 46 Dec 21 20:58 adjtime
drwxr-xr-x 2 root root 2048 Aug 10 11:51 alternatives/
[.... etc ...]
Sure looks like 3 sets of rwx to me...
Unfortunately... (Score:5, Informative)
$ 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.
Parent
Re: (Score:2)
Yes, but... (Score:2)
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 r
I don't think that's right... (Score:2)
If *everything* was setuid, it wouldn't matter whether you had administrator privilege or not. Also, runas wouldn't be needed for privilege escalation.
Re: (Score:3, Funny)
You know what? (Score:2)
I hope that by 2008 the desktop will be ready for GNU/Linux.
OT: ACLs (Score:5, Interesting)
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
Parent
Linux ACLs (Score:3, Interesting)
>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
Re: (Score:3, Informative)
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.
Re: (Score:2)
For example you could give CHANGE_PERMISSIONS to CREATOR_OWNER on \Users, to be inherited by subfolders and files only (not Users itself). Then a user can grant other people access to his or her files without having to be root (administrator).
In Windows, it isn't just the filesystem that supports ACLs; processes, kernel objects, etc all supp
Re: (Score:2)
This is largely a cultural thing left over from unix, which discarded ACLs in order to save space on the file system
Besides being a cultural thing, traditional unix filesystem permissions are far to entrenched for ACL's to take over. Does tar preserve anything but "owner, group, world"? Does Apache cope with ACL's? PHP? In all my travels, I've never once used ACLs or seen them used. Has anybody used them?
The bigger problem with ACL's in unix is the command line isn't a very good way to handle complex permissions. Complex permissions require complex displays. For example, using nothing but text, how do you show th
Re: (Score:2)
The reason(s) its not used are:
1 - too complicated. period.
2 - only NEEDED for 10% or less of the cases. The other 90% is handled nicely by uga permissions.
3 - see (1). Because it's THAT complicated, ACLs cannot be audited. Since the auditing is impractical, its not going to be done. As a DIRECT result, the calculus of ACLs must be such that ACLs can be effectively reasone
Re: (Score:2)
It's only too complicated on Linux. Heck, I'm be thrilled if Samba handled file permissions correctly let you change permissions without having to ssh in and do it as root. No problem though, I run my file servers on Windows where I don't have to mess with such crap.
Goof ups similar to your VMS example are very easy to run into under both Linux and Windows too. Try using the EXT extended attributes to apply acls. A few setuid tools totally ignore them, and they disappear with back and restore. Plus you
Re: (Score:3, Interesting)
I gave an example of where I've used ACL's in my post (a non root user try to give access to specific others to his files without giving everyone access). I also have run into a lot of other people who hit the same problem, but simply gave up because it couldn't be done without creating a whole new group, which they sometimes couldn't do... I suspect if you haven't noticed the limitations of user/group/everyone bits, you've been trying p
Re: (Score:2)
I'm saying in their current state, ACL's are unusable mainl
Re: (Score:2)
Linux ACLs are an implementation of POSIX 1003.1e draft 17. Every Linux. Everwhere. Maybe "still fairly new compared to the ACLs that are present in NTFS" is true.