Use filesystem capabilities (with setuid fallback) in packaging

Current list of things to do is here: https://wiki.ubuntu.com/Security/FilesystemCapabilties

Agenda and discussion from UDS:

I. Why should fscaps be used?
II. What are requirements for using fscaps
  A. Kernel
  B. User-space tools
  C. Filesystem support
  D. Packaging
III. Next steps

From Serge Hallyn:
1. Currently mounting an fs requires CAP_SYS_ADMIN. There are either 2 or 3
reasons for it: (1). the vfs mount action requires it. (2). The
fs-specific mount should
require it. And (3). some keychain operations might need it, though
they shouldn't
if the tools are properly set up. So I'll ignore (3). Regarding (1),
there has been much
work to remove the CAP_SYS_MOUNT requirement for the vfs mount. It has gotten
stuck basically because of the problem that an unprivileged user can prevent a
privileged user from deleting a directory by mounting something under
that directory
in a private namespace (so there is no way for the priv user to even
reference the
mount to address it). It's not that the problem is so hard to solve, more that
interest fizzled for now.

Regarding (2), the CAP_SYS_ADMIN requirement for an ecryptfs fs would
conceivable
never be lifted - doing so would require that we would trust the
ecryptfs_{read,write}
code enough that we'd be certain that it wouldn't cause any kernel oops/DOS/etc
regardless of what data it was fed.

So, the above background info seems like it would be good to put in an
intro to this
bug. Then, to answer the questions:

1. why use fscaps

fscaps should be used so that any exploit of the program would result in only
the granted capabilities being usable by the exploiter. By using
fI|pI, privileged use
of the program could also be restricted to certain users using pam_cap
(analogous
to sudo usage)

Note that I've looked at the current setuid-based code and was
satisfied that it is
very well written and robust, which is why I've considered this very
low priority work.
But still worth doing. Oh yes, there's another thing - a box which is
set up with
unprivileged root (prctl(PR_SET_SECUREBITS, 0x2f)) will still be able to use the
heper without have to make any changes.

2a. kernel requirements.

ubuntu kernel should have everything it needs enabled now
(CONFIG_SECURITY_FILE_CAPABILITIES)

2b. user-space tools

will require /sbin/setcap and /sbin/getcap (which are on my intrepid system, but
I may have hand-installed them). The sudo-like behavior with pI|fI
would require
pam_cap to be installed.

Steve Grubb at Fedora has a libcap-ng (in his redhat people/ dir) which has some
new programs to list all files, processes, or network-enabled processes with
file capabilities. Those might be useful to enable in this case (and
in any case).

The actual program will need to be modified to handle being started
with filecaps.
It will take some thought to decide onthe best way to handle backward compat of
the suid-root case (see below), but this has to be done anyway for
other programs.

(I intend to take a stab at that code "soon", though I simply must meet certain
deadlines on other projects first)

2c. fs support

filesystems must support the security.* extended attributes. To accomodate
filesystems which do not, we can still set setuid-root bit on the programs. Any
fs with file capabilities support will only fill the filecaps in the
xattr (if they are set).

2d. packaging

The security.capability xattr will have to be set on the installed
file. Perhaps the
user should get an option of which to set, the setuid root bit or the
capability,
as well as an option of whether everyone should get to run it, or only
some people.
If only some users, then the sudoers or
/etc/security/capabilities.conf files get set
up (and cap_sys_admin=ie set on the binary), else the setuid bit gets set or
setcap cap_sys_admin=fe on the binary.

3. Next steps:

An easy way might be set up for users to send their feedback, since this would
be a bit of a pilot program. We'll want to collect all feedback in
one place for
review.