I 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...
Eros 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.
Unix 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.
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.
I'd like to point out that large-memory/many-core multi-user machines are very much alive in Computational Science (Computational Physics, Computational Chemistry, etc). Usually as test-beds (before deploying on clusters), visualisation system, or simply front-end nodes for clusters.
In 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.
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?
Potentially, although it might need quite a lot of infrastructure to make that work usefully I think, as most of the design in Capsicum has been around reducing capabilities for a single group of programs for security, not a whole system. You can do much of that with Linux capabilities now - see man (7) capabilities and the section "The securebits flags: establishing a capabilities-only environment" which says how to disable suid so root is effectively removed.
"They are planning to sell Intel-based machines running Linux, with the SGI logo stamped on the box. They weren't very clear about the migration path they expect IRIX software to take, but they do seem to be very enthusiastic about Linux in general."
They chose Itanium as the new platform, and used the same technology as Apple did for Rosetta to smooth the transition between instruction sets (and in SGI's case, operating systems too).
13 comments
[ 2.3 ms ] story [ 40.2 ms ] threadBut 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...
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.
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.
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.
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.
They chose Itanium as the new platform, and used the same technology as Apple did for Rosetta to smooth the transition between instruction sets (and in SGI's case, operating systems too).
http://www.itjungle.com/tug/tug080405-story02.html