CAP_SYS_ADMIN: the new root

1. Besides their finer-grained nature, capabilities have another
advantage over setuid root: you lose the cap after exec. So shellcode
for execve(/bin/bash) doesn't grant a root shell by itself.

Put another way, your blog post starts with:

"The idea of capabilities is to break the power of root (user ID 0) into
independently assigned pieces governing specific privileged operations"

But the other fundamental property of capabilities is intended to be
that programs, not people, wield privilege, so that privilege is granted
to a combination of the logged in user and the program being execute.
Note that to fully achieve this programs ought to also lock themselves
into a noroot|nosuid_fixup securelevel.

2. Regarding breaking up some of the courser capabilities, I had
suggested making what we implicitly did with CAP_SYSLOG explicit, namely
introducing a hierarchy. At the top level, there is CAP_ALL_CAPS. This
is not quite the same as being root since after exec you can lose this
privilege. But of course it's enough power to let you ensure you can
keep your privilege. Then come most of the current ones, CAP_SYS_ADMIN,
CAP_NET_ADMIN, etc. Then come newer fine grained ones, like CAP_SYSLOG
and CAP_IPC_ADMIN.

Perhaps we can introduce through capability.h, through the use of some
annotations, a graph of the hierarchy, and a hierarchical way to refer
to the capabilities in the code. The point here is to let userspace
decide how fine grained to get. It can use CAP_SYS_ADMIN, or, over
time, choose CAP_SYSLOG. I think if we guarantee that a given
capability will never become insufficient privilege for what it could
previously achieve, that helps userspace.

Some privileges need to be reconsidered. For instance, it's been
pointed out that mount is dangerous because you can overmount /.
But really, there are several issues with mount:

1. Unprivileged mounts patches have been out there for years,
and apart from the issue of unpriv users preventing admins
from deleting files using mounts in unreachable namespaces,
it's understood hwo to allow many mount actions safely.
2. Mounting to targets which you don't own is obviously one
dangerous aspect to mount, as you can overwrite "trusted
paths" like /sbin or /etc.
3. Lack of trust in the in-kernel filesystem (and especially
super block) parsers is another, separate concern. You may
be able to write garbage to a file, mount it loopback, and
cause ext2's read_super to crash the kernel (or worse).

3. Analysis. Thanks for the great ideas. I've somewhat lost track of
kernel dev cycles, but your idea to analyze changes to capabilities at
rcs is a great one, and I should act on it. I also should reproduce and
expand on the analysis of the current capability checks that you've
done.