

CAP_SYS_ADMIN: the new root - sounds
http://lwn.net/Articles/486306/

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

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

This sounds...sort of familiar...

(<http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs>)

Sadly; *nix was just good enough.

~~~
luriel
Of particular interest is the paper on Plan 9's security model:

<http://doc.cat-v.org/plan_9/4th_edition/papers/auth>

------
casca
FreeBSD 9 has another neat option - 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
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.

------
Peaker
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>

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

