Re: posix capabilities inheritance
From: Andy Lutomirski
Date: Fri Oct 24 2003 - 16:24:54 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/