lkml.org 
[lkml]   [2000]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans