Bug in how capability inheritance is handled in "fs/exec.c", 2.3.99

From: Linda Walsh (law@sgi.com)
Date: Sat May 27 2000 - 22:34:15 EST


Going by the Posix that capabilities are modeled after,
using notation p=process, f=file, "'" (prime) = new, P=Permitted, I=Inherited and
        E=Effective
1) pI' = pI & fI ; this allows either the running process OR the file to
                        ; limit what capapabilities can be passed in (Permitted) to
                        ; the new process; this way either a user or a program can
                        ; limit permissions being inherited by the new process

2) pP' = fP | (pP & pI')
                        ; this implies that first any non-inheritible bits are
                        ; stripped out of the old permitted set, then the remaining
                        ; process P-bits are or'ed with explicit Permitted permissions
                        ; that are on the file.
3) pE' = fE & pP'
                        ; this sets the effective set of the process to the desired
                        ; effective set of program bounded by the new Permitted
                        ; cap set.

-----------
        The comment in 'compute_creds' (fs/exec.c) leaves out the inclusion
of the previous process's Permitted bits. This Disables the possibility
of running a given UID running with specific Capabilities to perform
specific actions (UID's having 'roles', independant of FS settings) --
for example, if someone wanted to run with a 'root' type user in a
capability environment (say user=admin, has all caps and can only login
on the console) -- (policy for that setup being if an admin has access to console
and physical machine, they can pretty much do as they want).ly
        Secondly, the comment doesn't reflect the code -- the effective set
is never computed.

        It is said in the POSIX DS, that the effect of executing a file w/no
capabilities is undefined.

        I would propose the ability to set this up as a mount option like
'noroot' or 'nosuid'. Administrators could setup a file system mount with
a "default" Permitted, Inheritable and Effective set. Any mount where it
is not specified takes on the set of the "parent' filesystem. Default for
/root for PIE could be none,all,all -- this could be a configurable at
compile time. The default of PIE=NAA would be equivalent to current behavior --
No file grants a capability, but they all can inherit them and ask for all --
so current root with AAA would get pI' = A, pP' = A, pE' = A (current behavior).
In other words mounts would have no effect on systems retaining their current
configuration.

        Of course mount options would be in the kernel superblock of a mounted
fs only, not on disk.

--
Linda A Walsh                    | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338                        _cr

- 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/



This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:18 EST