Messages in this thread | | | Date | Sun, 20 Feb 2000 18:00:09 +0100 | From | Andreas Gruenbacher <> | Subject | Re: Capabilities |
| |
Khimenko Victor wrote: > > [a lot of strange things]
There seems to be some confuson about what Capabilities are, and how they are related to SUID binaries and filesystems.
- A process is associated with the three sets of capabilities Inheritable, Permitted and Effective (I, P, E). It may temporarily suspend capabilities, and permanently drop capabilities. It also controls which capabilities are inherited by child processes.
- Binaries should also be associated with the same three sets of capabilities (If, Pf, Ef). This is not yet implemented, which is why we don't yet have a more ``Trusted Linux''. When a binary is exec()ed, the new process should get the following capabilities (Posix 1003.1e DS17; X is an implementation defined value):
(I1, P1, E1) = (I0, (Pf & X)|(If & I0), Ef & P1)
A child process after exec() may thus have fewer or more capabilities than its parent process.
- In the current Kernel, root is omnipotent. Before Capabilities, root was grant everything based on its uid. With the current implementation of Capabilities, SUID root binaries get full capabilities from exec(). (Capabilities may still be dropped, but the next SUID root binary will again be omnipotent).
- What we really want for ``Trusted Linux'' is something else. Root should not be treated differently based on its uid. The capabilities of a new process should only be derived from the Inheritable set of the parent process, and the capabilities of the binary.
- Once we have file-based capabilities, we can implement that. Here, the idea I posted before (which was shamelessly stolen from another OS) can be used. The kernel boots in ``non-trusted'' mode; SUID root binaries get all capabilities. A process in the init scripts then switches the system into ``trusted'' mode. After that, SUID root binaries are treated no different anymore.
Switching to ``trusted'' mode is a system-wide decision, and is not filesystem based. Switching could be one way, or it could be ruled by a capability (if people really think it's necessary to switch back to ``non-trusted'' mode). In the latter case, that capability could still be disallowed on filesystems (see the X mask), so dropping that capability in all running processes would still give a high level of trust.
For those who don't know yet, Posix 1003.{1e,2c} Draft Standard 17 is freely available at <http://www.guug.de/~winni/posix.1e/download.html>.
Hope my confused words are still helpful.
Regards, Andreas
------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~agruenba
- 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/
| |