Re: posix capabilities inheritance

[Andy Lutomirski <luto@stanford.edu>]

David Wagner wrote:

> Andy Lutomirski  wrote:
> 
>>I've been programming Windows for a long time, and windows has a 
>>capability system.  [...] All capabilities are disabled by default (almost -- 
>>there's a pointless exception, of course).  The result is that every 
>>program that uses a privileged function (e.g. change the time, restart, 
>>etc.) wraps that call with something that turns enables the capability 
>>at first, then disables it.  This has no benefit -- a hijacked 
>>privileged program can still enable them, and the admin never sees this, 
>>because everything enables them.
> 
> 
> Actually, it does have some benefits.  If I do an open() somewhere
> else in the code, I know that it is not going to unintentionally use
> my elevated privileges.  That's useful.  Least privilege, and all that.

Agreed, somewhat. The problem IMHO is that, even for caps like 
CAP_DAC_READ_SEARCH, no existing code expects this behavior.  (Windows 
example again: users with SeBackupPrivilege have a _very_ hard time 
using it since few programs actually know what to do with it.)  If I'm a 
user with CAP_DAC_READ_SEARCH, I don't want to have to rewrite all of 
fileutils just to use that privilege.  Users can still have this 
behavior, though, under my proposed evolution rules:
pE' = pP' & (pE|fP)

Pretend that 'cap' is a bash builtin that did the obvious thing:

~backupuser/.bashrc: cap all disable
~backupuser/bin/privrun: cap all enable; exec $*

Now that user can't accidentally use CAP_DAC_READ_SEARCH, but s/he could 
do 'privrun ls', for example, if necessary.  (I'm ignoring funny issues 
with cd here.)  All of this is without the fE mask and without modifying 
or breaking existing user tools.

If you can think of a use for fE, let me know :)


Andy