Re: posix capabilities inheritance
From: Andy Lutomirski (luto_at_stanford.edu)
Date: 10/24/03
- Previous message: Krzysztof Halasa: "[PATCH] Goramo PCI200SYN sync serial card driver for 2.4.23pre8"
- Maybe in reply to: Michael Glasgow: "posix capabilities inheritance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 24 Oct 2003 14:24:00 -0700 To: David Wagner <daw@cs.berkeley.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Krzysztof Halasa: "[PATCH] Goramo PCI200SYN sync serial card driver for 2.4.23pre8"
- Maybe in reply to: Michael Glasgow: "posix capabilities inheritance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
