Re: [patch 2.1.97] more capabilities support

Albert D. Cahalan (acahalan@cs.uml.edu)
Mon, 20 Apr 1998 01:33:15 -0400 (EDT)


>> [ .. we need a "bounding set" .. ]
>
> To address your suggestion of needing a "bounding set", I hope to show
> with the following example that this is actually accommodated within
> the current model.
>
> Consider a dangerous command like 'rm'. Everyone needs to use it to
> maintain their own files but, traditionally, in the hands of an admin
> user like root no file is safe.
>
> It is instructive to see how root's historic ability to delete
> arbitrary files is made available to a select set of users without
> risking 'nobody' from stealing this capability. The key thing is the
> pI capability.
>
> These are the implemented rules for propagating capabilities following
> a sys_exec() call:
>
> pI' = pI
> pP' = fP | (fI & pI)
> pE' = pP' & fE [NB. fE is 0 or ~0]
>
> For the purpose of this discussion (and without loss of generality ;^)
> we shall say that each of these symbols represent just the "remove
> arbtrary files" capability (CAP_FOWNER).
>
> The 'rm' executable is given the following file-capabilities:
>
> fP = 0; fI = 1; fE = 0.

No, consider a setuid (traditional & file capability) tool that
cleans out /tmp, removes print jobs, etc.

> Now, consider two users: nobody and admin.
>
> 'nobody' logs in and is given a shell. Login arranges that the shell
> nobody runs has the following Inheritable capability: pI = 0.
> Similarly, the shell runs with pE = pP = 0.

The tool gets these:

pI' = 0 = 0
pP' = 1 | (1 & 0) = 1
pE' = 0 & 1 = 0

If I read that right, the tool is permitted to raise the capability
but there is no capability to raise. (must pI also be 1 to raise pE?)

I think I still see a problem. Only the one capability has been
disabled, so operations that require it will fail. Other privileged
operations won't fail though, so the tool could create a mess when
it runs. For example, the tool may notify a daemon of whatever
action it will do.

Hopefully such problems are uncommon.

> The neat thing here is that the shell, which is common to both users,
> is unable to make use of the Inherited capabilities because it has no
> file capabilities with which to snag them.

That is quite weird. What about compatibility problems?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu