First the standard rules upon exec:
1. pI'=pI
the process Inheritable set is passed unchanged through the exec()
2. pP' = fP | ( fI & pI )
I would argue should be pP' = fP | ( fI & pI & pP ) normally! The posix
drafts say it can be pP' = (fP & x) | ( fI & pI ) where x is
implementation defined. I shall return to x later.
the process' permitted set becomes the combination of the permitted set of
the exec()'d file and those inheritable capabilities
of the exec()ing file that are also inheritable by the file.
I would argue that the inheritance should be further tempered by the
parent processes permissible cap set.
3. pE' = fE & pP'
This is how the standard how I think that new sets should be calculated
after an exec if you have trusted information from either ext3 attributes,
or ELF headers in suitable marked executables. I will be chicken and not
enter the suid-root Vs. sticky-immutable war. Except a quick mention that
suid-root should store a uid and a failback mode indicator, so you can
on non-cap kernel choose to either EPERM, act like old suid-root, set euid
to ruid, set euid to stored elf uid.
The default for unheaded or unmarked binaries I believe should be as if it
was fI=-1, fP=0, fE=-1, x=0. 0 being none and -1 being all-- which reduces
the formulas to:
1. pI'=pI -- no surprise here
2. pP' = pI
which I would argue should be pP' = pI & pP
3. pE' = pI
Again I'd argue pE' = pI & pP
For headed elf binaries not specially marked I'd use the following
formulas setting x to 0:
1. pI' = pI
2. pP' = ( fI & pI & pP )
3. 3. pE' = fE & pP'
This has the effect of ignoring fP which is far more dangerous than fI
ever was.
fI never raises any cap sets without filtering through other masks.
I do think that it is critical to mask it with the parents processes
permissible mask to make sure things stay better secured especially for
unmarked elf headers or my default situation.
I think non-marked elf header binaries as I have defined them are a fair
extension of the draft as section B.25.2.8 which allows extensions as long
as they are constraints and decrease capabilities.
Further more I believe that the spirit and intent of the posix drafts I
have read and the above web page reference indicate to me that it is the
intended behavior for capabilities inheritance control is mostly to fall
upon the parent process and not on the file attributes.
In the case of apathy the standard also seems to assume the caps should
inherite.
Anyway comments welcome.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/