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.
