Linux, IRIX and “Posix Capabilities” (1999)
eros-os.org
Linux, IRIX and “Posix Capabilities” (1999)
1–10 of 14 posts
Re: Linux, IRIX and “Posix Capabilities” (1999)
#2I wasn't aware of the original, more useful meaning of "capabilities". Linux really has spread the "posix capabilities" meaning most widely.
But I was aware that most linux capabilities can pretty easily get you full root: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 (I'm really not a fan of linux/posix capabilities, they should probably just be forgotten.)
There's also this thing that's primarily on FreeBSD called "capsicum" which is also a "capabilities" model which I've heard is more secure/useful but really don't know anything about. Lots of relevant links: https://www.lightbluetouchpaper.org/2013/12/20/2013-capsicum...
Re: Linux, IRIX and “Posix Capabilities” (1999)
#3Eros and KeyKOS had some very interesting ideas in addition to capabilities.
Global process persistence meant that you could pull the plug on a running system and start it back up right where it left off. It was constantly journalling system activity onto permanent storage. This also provided some level of system roll-back, kind of like a database but applied to the whole OS and all its activities.
Something like that could be very useful on low power intermittent use devices like smartphones.
Re: Linux, IRIX and “Posix Capabilities” (1999)
#4Unix permissions become increasingly complicated while usage moves in the other direction.
Complex permissions were a must-have in the era of time-shared systems. You'll find some slow-moving multinationals that still have people shelled into production unix boxes, and where they have thick policy manuals around who is allowed to become what kind of user. But it's on the way out.
Two use-cases dominate now: unix servers that nobody ever shells into. They boot into a prepared image, or have configuration pushed to them. And - single-user workstations.
Re: Linux, IRIX and “Posix Capabilities” (1999)
#5Unix permissions become increasingly complicated while usage moves in the other direction. Complex permissions were a must-have in the era of time-shared systems. You'll find some slow-moving multinationals that still have people shelled into production unix boxes, and where they have thick policy manuals around who is allowed to become what kind of user. But it's on the way out. Two use-cases dominate now: unix serv…
What about mobile devices with partially trusted (or even untrusted) apps?
Re: Linux, IRIX and “Posix Capabilities” (1999)
#6Unix permissions become increasingly complicated while usage moves in the other direction. Complex permissions were a must-have in the era of time-shared systems. You'll find some slow-moving multinationals that still have people shelled into production unix boxes, and where they have thick policy manuals around who is allowed to become what kind of user. But it's on the way out. Two use-cases dominate now: unix serv…
What about mobile devices with partially trusted (or even untrusted) apps?
Your comment raises a solid use-case I hadn't mentioned: unix running underneath a single-user mobile device.
You do need permission systems for that scenario. But they don't have to be in the OS. You could implement them in the application container.
A difficulty with security services being tied to the OS is that you're tied to the featureset of the OS, which tends to have a slow-moving API. Much better to implement security via library, so it can move at the same pace as your application platform.
There are many ways to build a unix. Unix is strong at hardware interaction (drivers, filesystems), IPC, process control. Security models dilute it. This includes chmod-style filesystems permissions in that. It's lots of complexity that delivers little value.
Curious: Stallman built GNU on unix. He's an open guy himself, and had spent a lot of time with MIT systems that didn't implement security in the OS level.
Re: Linux, IRIX and “Posix Capabilities” (1999)
#7In linux cgroups and namespaces effectively are a better model. I wonder if internally posix capabilities could just be re-implemented over cgroups instead.
Re: Linux, IRIX and “Posix Capabilities” (1999)
#8Eros and KeyKOS had some very interesting ideas in addition to capabilities. Global process persistence meant that you could pull the plug on a running system and start it back up right where it left off. It was constantly journalling system activity onto permanent storage. This also provided some level of system roll-back, kind of like a database but applied to the whole OS and all its activities. Something like tha…
More details and an amusing story involving Novell: http://www.eros-os.org/project/novelty.html#persistence
Re: Linux, IRIX and “Posix Capabilities” (1999)
#9In linux cgroups and namespaces effectively are a better model. I wonder if internally posix capabilities could just be re-implemented over cgroups instead.
They are a limited model. Namespaces do allow you to pass access tokens between processes, but these are limited as mostly you can only be in one namespace at a time, so they are not usefully compositional. You can never be in more than one cgroup of the same type, and you cannot pass your capabilties on.
Capsicum is a real capabilities system, as is being discussed in the article, where capabilities are attached to file descriptors. So for example process descriptors in Capsicum are file descriptors that refer to a process, if that design was pervasive you do not need process namespaces as you can only see processes you have a descriptor for.
Re: Linux, IRIX and “Posix Capabilities” (1999)
#10In linux cgroups and namespaces effectively are a better model. I wonder if internally posix capabilities could just be re-implemented over cgroups instead.
They are a limited model. Namespaces do allow you to pass access tokens between processes, but these are limited as mostly you can only be in one namespace at a time, so they are not usefully compositional. You can never be in more than one cgroup of the same type, and you cannot pass your capabilties on. Capsicum is a real capabilities system, as is being discussed in the article, where capabilities are attached to…
Wouldn't capsicum then allow to effectively implement different user models than root/user? Where the login process would be responsible to just drop capabilities after switching the uid?