
Linux, IRIX and “Posix Capabilities” (1999) - vezzy-fnord
http://www.eros-os.org/pipermail/e-lang/1999-November/003031.html
======
porlw
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.

~~~
biot
More details and an amusing story involving Novell: [http://www.eros-
os.org/project/novelty.html#persistence](http://www.eros-
os.org/project/novelty.html#persistence)

------
cturner
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.

~~~
lmz
What about mobile devices with partially trusted (or even untrusted) apps?

~~~
cturner
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.

------
ploxiln
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](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...](https://www.lightbluetouchpaper.org/2013/12/20/2013-capsicum-
year-in-review/)

------
jtanworth
"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).

[http://www.itjungle.com/tug/tug080405-story02.html](http://www.itjungle.com/tug/tug080405-story02.html)

------
tenfingers
In linux cgroups and namespaces effectively are a better model. I wonder if
internally posix capabilities could just be re-implemented over cgroups
instead.

~~~
justincormack
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.

~~~
tenfingers
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?

~~~
justincormack
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.

