6 ms·

CAP_SYS_ADMIN: the new root

103 points by sounds 15y ago

casca 15y ago
FreeBSD 9 has another neat option - Capsicum (http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/). If you're interested in a good way forward, have a look. Authorization will always be hard because working out what each person should be able to access and then giving a meaningful way of describing that is hard.
- rwmj 15y ago
  Full marks to FreeBSD for turning research into a practical application. Sadly I'm not hopeful for the Linux community, which routinely ignores and disparages research and innovations from outside itself.
cturner 15y ago
Why are they going deeper with it? The more I deal with unix, the more I feel that permissions are a mistake. That wasn't always true. In the past, it was common to have having multiple untrusted users in one system. Outside of universities that is now uncommon. It's much more typical to have one operator own (or a small team share) a large number of unix hosts. The common models here for dealing with privileges are more an exercise in getting aroung it than leveraging it. One model is to have an app user that everyone logs in as. This reduces the change of people making a mistake when they're root, but it's hard to know who did what. Another model has each person have a unique user. They log in as themselves and then sudo to application users. It's a fair bit of work to set up, and once you have you still don't get to see who ran what command. In theory you can set things up so that everyone is in the same group, but there's fiddly problems when you do this. Like you can't copy over someone else's file (even if you're in the group and it's 775), you have to first delete it and then copy in its place. A model I'd prefer would be to have a gateway OS housing multiple VMs. A vm would have full rwx access to a mount point on a filesystem. Any user within the vm would have full permissions. The system would log into the gateway system. If you had particular security needs, you'd implement them at an application level. Privileges make the unix code and user experience significantly more complicated. I don't see a payoff that justifies the cost.
- nwmcsween 15y ago
  Posix 'capabilities' are a neutered version of actual capability security such as capsicum in FreeBSD. Linux is trying somewhat to go this way with seccomp2 and perf but Linux is Linux and things usually evolve by bolting on additions instead of fixing the core problem. I honestly don't see why Linux doesn't adopt capsicum instead of reinventing the same thing.. poorly.
- dfc 15y ago
  "In the past, it was common to have having multiple untrusted users in one system. Outside of universities that is now uncommon." Is this a personal anecdote or do you have actual evidence? More importantly your discussion of users/privileges does not take into account separate users for separate processes within the system. Do you think postfix/mysql/apache/whatever-daemon should all run as the same user? Different daemons are essentially different untrusted users and I am glad that unix treats them this way. Without separate users how do you do backups safely and reliably? I am not positive but I think that a modern windows system has different users for different processes..
- sounds 15y ago
  Some of the privilege "jails" on a unix system are for programs. Android jails each app by assigning it a unique user ID. [1] I actually agree with you - the Posix privilege model is dated. But it's still working fine, with additions like the MAC (SELinux), xattr's and ACLs, and now capabilities. [1] http://www.slideshare.net/pragatiogal/understanding-android-security-model http://www.slideshare.net/pragatiogal/understanding-android-... slide 5/30
  - vog 15y ago
    For a long time, I was using Linux-VServer (that's a "BSD jails" equivalent for Linux). It worked really well. But it allowed only for Linux guest systems, and the virtual networking often had some unexpected holes and flaws (maybe "BSD jails" work better in that regard). However, with the arise of KVM (and other virtualization systems that no longer slow down your guest systems), I'm switching to KVM for those tasks.
- 15y ago
zobzu 15y ago
As many discuss the cap sys admin for processes, I'd like to point out that, some framework exists to alleviate the issue. It's not perfect but it exists. For example RSBAC (www.rsbac.org) has a CAP module and which can forbid capabilities per process. This won't save you when the kernel request it, but it doesnt when an app require it while it doesn't need it, which is what the article is about
- nwmcsween 15y ago
  The problem with non integrated solutions (integrated as in in the application) is that people need different access restrictions depending on their specific use case.. This had led to what you see now in Linux with apparmor, grsec, selinux, smack, tomoyo, rsbac all with different incompatible outside solutions that don't really solve the problem or introduce a huge amount of technical overhead that only the developer of said application would have knowledge about. In short their useless due to time and effort needed.
  - zobzu 15y ago
    No, actually, RSBAC does this via policy. That is, the developer does not need to bother. The developer does what the developer does. The policy enforces it, regardless of the code. If in certain conditions, as a user, you disagree with the user of CAP_SYS_ADMIN, RSBAC denies it (context-based too, via other modules!) You can for example wrap that in a role-based policy, tied per binary, or simply by wrapping it in a RSBAC jail. (rsbac_jail -options /path/to/said/program) I don't think the other ones do that, as it's quite specific. They just plain deny. That's mostly because RSBAC has it's own framework (as does GrSecurity, but GrSecurity does not go as deep in that regard)
zurn 15y ago
I always understood the point being to split off some capabilities that can be used on their own safely, and leave the rest under CAP_SYS_ADMIN. Stuff like ability to bind to ports <1024 or configure network interfaces. So if most of the stuff stays under CAP_SYS_ADMIN, the system is working as designed.
Peaker 15y ago
I wonder if the name "capabilities" was intentionally chosen to be confused with the "object capability" security model, which is a completely different beast. Object capabilities would bring reasonable security to the OS, so we wouldn't have to use clumsy VM's as a security model. Unfortunately, the mistake of the 1960's (ACL-based security) stuck to this day, and object-capabilities were barely put to use. http://en.wikipedia.org/wiki/Object-capability_model http://en.wikipedia.org/wiki/Object-capability_model

103 points by sounds 15y ago

casca 15y ago

FreeBSD 9 has another neat option - Capsicum (http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/). If you're interested in a good way forward, have a look. Authorization will always be hard because working out what each person should be able to access and then giving a meaningful way of describing that is hard.

rwmj 15y ago
Full marks to FreeBSD for turning research into a practical application. Sadly I'm not hopeful for the Linux community, which routinely ignores and disparages research and innovations from outside itself.

cturner 15y ago

Why are they going deeper with it? The more I deal with unix, the more I feel that permissions are a mistake. That wasn't always true. In the past, it was common to have having multiple untrusted users in one system. Outside of universities that is now uncommon. It's much more typical to have one operator own (or a small team share) a large number of unix hosts. The common models here for dealing with privileges are more an exercise in getting aroung it than leveraging it. One model is to have an app user that everyone logs in as. This reduces the change of people making a mistake when they're root, but it's hard to know who did what. Another model has each person have a unique user. They log in as themselves and then sudo to application users. It's a fair bit of work to set up, and once you have you still don't get to see who ran what command. In theory you can set things up so that everyone is in the same group, but there's fiddly problems when you do this. Like you can't copy over someone else's file (even if you're in the group and it's 775), you have to first delete it and then copy in its place. A model I'd prefer would be to have a gateway OS housing multiple VMs. A vm would have full rwx access to a mount point on a filesystem. Any user within the vm would have full permissions. The system would log into the gateway system. If you had particular security needs, you'd implement them at an application level. Privileges make the unix code and user experience significantly more complicated. I don't see a payoff that justifies the cost.

nwmcsween 15y ago
Posix 'capabilities' are a neutered version of actual capability security such as capsicum in FreeBSD. Linux is trying somewhat to go this way with seccomp2 and perf but Linux is Linux and things usually evolve by bolting on additions instead of fixing the core problem. I honestly don't see why Linux doesn't adopt capsicum instead of reinventing the same thing.. poorly.
dfc 15y ago
"In the past, it was common to have having multiple untrusted users in one system. Outside of universities that is now uncommon." Is this a personal anecdote or do you have actual evidence? More importantly your discussion of users/privileges does not take into account separate users for separate processes within the system. Do you think postfix/mysql/apache/whatever-daemon should all run as the same user? Different daemons are essentially different untrusted users and I am glad that unix treats them this way. Without separate users how do you do backups safely and reliably? I am not positive but I think that a modern windows system has different users for different processes..
sounds 15y ago
Some of the privilege "jails" on a unix system are for programs. Android jails each app by assigning it a unique user ID. [1] I actually agree with you - the Posix privilege model is dated. But it's still working fine, with additions like the MAC (SELinux), xattr's and ACLs, and now capabilities. [1] http://www.slideshare.net/pragatiogal/understanding-android-security-model http://www.slideshare.net/pragatiogal/understanding-android-... slide 5/30
- vog 15y ago
  For a long time, I was using Linux-VServer (that's a "BSD jails" equivalent for Linux). It worked really well. But it allowed only for Linux guest systems, and the virtual networking often had some unexpected holes and flaws (maybe "BSD jails" work better in that regard). However, with the arise of KVM (and other virtualization systems that no longer slow down your guest systems), I'm switching to KVM for those tasks.
15y ago

zobzu 15y ago

As many discuss the cap sys admin for processes, I'd like to point out that, some framework exists to alleviate the issue. It's not perfect but it exists. For example RSBAC (www.rsbac.org) has a CAP module and which can forbid capabilities per process. This won't save you when the kernel request it, but it doesnt when an app require it while it doesn't need it, which is what the article is about

nwmcsween 15y ago
The problem with non integrated solutions (integrated as in in the application) is that people need different access restrictions depending on their specific use case.. This had led to what you see now in Linux with apparmor, grsec, selinux, smack, tomoyo, rsbac all with different incompatible outside solutions that don't really solve the problem or introduce a huge amount of technical overhead that only the developer of said application would have knowledge about. In short their useless due to time and effort needed.
- zobzu 15y ago
  No, actually, RSBAC does this via policy. That is, the developer does not need to bother. The developer does what the developer does. The policy enforces it, regardless of the code. If in certain conditions, as a user, you disagree with the user of CAP_SYS_ADMIN, RSBAC denies it (context-based too, via other modules!) You can for example wrap that in a role-based policy, tied per binary, or simply by wrapping it in a RSBAC jail. (rsbac_jail -options /path/to/said/program) I don't think the other ones do that, as it's quite specific. They just plain deny. That's mostly because RSBAC has it's own framework (as does GrSecurity, but GrSecurity does not go as deep in that regard)

zurn 15y ago

I always understood the point being to split off some capabilities that can be used on their own safely, and leave the rest under CAP_SYS_ADMIN. Stuff like ability to bind to ports <1024 or configure network interfaces. So if most of the stuff stays under CAP_SYS_ADMIN, the system is working as designed.

Peaker 15y ago

I wonder if the name "capabilities" was intentionally chosen to be confused with the "object capability" security model, which is a completely different beast. Object capabilities would bring reasonable security to the OS, so we wouldn't have to use clumsy VM's as a security model. Unfortunately, the mistake of the 1960's (ACL-based security) stuck to this day, and object-capabilities were barely put to use. http://en.wikipedia.org/wiki/Object-capability_model http://en.wikipedia.org/wiki/Object-capability_model