Messages in this thread | | | Date | Fri, 23 Apr 1999 01:25:24 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: file effective and process inheritable mask |
| |
David L. Parsley writes:
> 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/
| |