1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
-*- text -*-
* NOTE: This information predates all of the elfcap stuff in the
kernel. I have no idea how things will work in combination with it. If
you do, drop me a note :)
These are capability inheriting rules (ie, what happens across an
exec).
pI' = pI
pP' = fP | (fI & pI)
pE' = pP' & fE
Currently (as of 2.2.3)
On exec, fI and fE is always 0 to a non-root process, and ~0 to a
non-root process.
On setuid away from root, pP and pE are cleared.
The upshot of this is that once you setuid to anything other than
root, you lose all of your capabilities (pE == 0), can't regain them
by asking (pP == 0), and can't regain them by exec (fE = 0).
OTOH, if you *are* root, then you can remove capabilities from
yourself. This is nice, but there doesn't appear to be any way to
remove things like basic RW access to root owned files.
I've written a patch to play with this a bit (available from
http://www.eris.rcpt.to/rlinetd). Its effects:
On exec, fI and fE are unconditionally ~0.
On setuid away from root, pI and pE are cleared.
The upshot - an application may raise capabilities up to it's
permitted set after a suid. If it does not do so (ie, capability
unaware), it will permanently lose all capabilities after an exec (pP
== 0). Playing with capabilities on root processes does not
necessarily do what you expect.
Security note - this provides a danger window. A capability unaware
application will assume that a setuid permanently discards all
privileges. In reality, this is not the case until it performs a
subsequent exec.
Another note - if a process is not uid 0 but has cap_setuid raised,
then performing a setuid will NOT clear the inheritable and effective
sets. The theory is that if a non-root process has any capabilities,
it should bloody well know what to do with them.
=eip will not work, due to CAP_SETPCAP being disallowed. this is not
necessarily a bad thing :)
|
