Re: posix capabilities inheritance

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Oct 23, 2003 at 05:05:40PM -0500, Michael Glasgow wrote:
> Even with selective capability inheritance enabled in this fashion,
> it is still possible to avoid using it and modify programs directly,
> if you think that's more secure.  Personally, I think that in some
> cases it's slightly more secure to have a very small (statically
> linked) setuid wrapper program which sets up capabilities properly
> than to make a very large program setuid-root (when it was not
> designed to run as root), only to add one capability.
> 
> Yes, you can do the capability-setup first thing in main()... but
> this is occasionally insufficient.  Also, it makes it a pain to
> have, for instance, a backup user with CAP_DAC_READ_SEARCH who is
> able to run several apps, e.g. dump, tar, cpio, rsync, etc.  from
> a restricted shell.
> 
> The code to drop privs is not hard, but it's also not trivial.
> Those without a clue are just as likely to screw it up as they are
> a wrapper; and anyway since when did it become a design goal for
> the kernel to cater to the ineptitude of the clueless?  That sounds
> more like a Redmond, Washington philosophy than one fit for Linux. :-)

Modifying source code requires programming capabilities, which means
that the most clueless won't do it at all.  It's something that needs
to be done by the upstream authors, or perhaps by the distributions,
at which point the clueless will get it when they upgrade.

It's not matter of catering to the ineptitude of the clueless but
pursueing a design which doesn't leave an open manhole cover where a
clueless system administrator can screw up and put their entire system
at risk.  Consider that even if the distributions ship a package using
your system, there will be a config file which will be an opportunity
for a system administrator to screw up.  In general, for any
particular system program, there is only one acceptable setting in
terms of what capabilities it will need.  So why make it be something
which can be screwed up in a config file?  

Fix it once, by a programmer who knows what he/she is doing, and the
problem is fixed for everyone.  Furthermore, it will be more efficient
since it avoids an exec and requirement for a program to parse a
config file.

						- Ted