> real-world use. One is that the file effective set seems superflous;
> i.e., if the program is _not_ capability aware, the effective set for the
> new process should just be equal to the permitted set, otherwise the
> program won't be able to accomplish it's job; if it _is_ capability aware,
> then it should manipulate it's own effective set. So really, I still
> don't see why we need fE (file effective).
Consider these types of marked executables:
dumb, without privilege fE should be empty
dumb, with privilege fE should be equal to fP
smart fE should be empty
We really only need one bit to indicate if an executable is aware,
but there is no harm in using a whole set of bits.
> Two, (and I'm thinking mostly here about non-cap-aware binaries),
> it seems like it would be nice to be able to constrain the passage of the
> inheritable set using our cap-elf model. I'm referring to an fM, where it
> masks off bits in the inheritable by the formula pI' = pI && fM. This
> occurs to me after thinking about an admin account starting a program by
> hand, where the shell might have a mostly full inheritable set. This
> seems like a bad security issue, since that program can exec() another
> program with a more potent inheritable set.
You are supposed to be able to do that. Think of it being a bit like the
ability to run a normal setuid-root executable. Normal users are allowed
to do that. It would be silly to only let already-privileged users run
privileged executables.
The fI vs. fP distinction lets you have capabilities that are activated
for a subset of the users, those who already have the bits in pI.
> I've read that the idea is for privs to be able to pass though a
> chain of programs which themselves may have little or no pP, which is
> fine, but IMHO it would be nice to stop this effect for many binaries.
> (still thinking of named, telnetd, ... system services)
The draft model does not seem to provide this ability. It could in fact
be dangerous, since privileged executables with poor error checking could
crash when they get insufficient capabilities.
Besides confusion and tech support trouble, crashes can allow DoS attacks
and possibly worse.
The two most important extensions IMHO are:
1. The ability to mark an executable with the minimum capabilities
needed to properly execute. This helps avoid crashes.
2. The ability to mark an executable with the capabilities that were
known to the setup tool. The kernel can use default values for any
bits that are not listed. This lets kernel developers add new bits
for traditionally unprivileged operations and lets them split old
bits into more fine-grained sets of bits.
After those two, I think it would be nice to allow configurations that
are halfway between traditional behavior and the draft. One could let
the more harmless capabilities (resources, read access...) be passed
to child processes automatically, while enforcing the draft behavior
for more destructive capabilities.
-
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/