Re: [patch 2.1.97] more capabilities support

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

>>> 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]
>>>
>
>>> 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.
>
>> 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?)
>
> Sorry, I guess I was not clear on this. The only requirement for a
> process to raise an effective capability is that its Permitted
> capability (pP' here) is raised. In the case that you cite here,
> the fact that pP' is 1 implies that the process is permitted to raise
> its pE' with a system call.

So "nobody" gets to use the "remove any file" capability.
IMHO it would be nice to be able to stop that.

Considering users as:

a. authorized to use the capability as desired
b. limited by tools & not expected to find holes in the tools
c. possibly serious crackers who are likely to look for holes

User "nobody" is in group c, and should not be able to
execute tools with such power.

> In point of fact your example, if I read it right, when written out in
> full has the following form(s):
>
> Strict capability model (cleanme.tool has file capabilities):
> cleaner: (pI = 0; pP = ? ; pE = ?)
> cleanme.tool: (fI = 1; fP = 1 ; fE = 1)
> cleaner-running-cleanme.tool (pI'= 0; pP'= 1 ; pE'= 1)
>
> Backward compatibility model (cleanme.tool is setuid root):
> cleaner: (pI = 1; pP = 0 ; pE = 0)
> cleanme.tool: (fI = 1; fP = 0 ; fE = 1)
> cleaner-running-cleanme.tool (pI'= 1; pP'= 1 ; pE'= 1)
>
> Note, I have corrected the pE' since it is derived
> from pP' (and not pP).
>
> If your claim is that when the cleanme.tool runs it will fail to
> execute the unlink() operation on files it doesn't own, I hope I've
> cleared that up.

Just the opposite: the user must not have access to tools with
that kind of power because the tools might be buggy.

>>> 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?
>
> The only compatibility problems (in the compatible mode) arise if you
> start clearing bits in the pI capability set... The way backward
> compatibility is currently configured, the pI set is never changed
> from { ~0 }.
>
> It is an interesting feature of the model that should you start
> clearing bits in pI you can ensure that without filesystem support for
> capabilities you can back the root account into a corner... This is
> especially useful for chroot cells...

I'm thinking of the shell removing files. The closest I can imagine
is with redirection. Would that fail? Maybe it is good, but it
doesn't seem very compatible.

> [I'm going to put all this in the documentation. I strongly suspect
> other people will find it handy.. ;]

Yes, until we have enough features to need a full HOWTO on them.
(did you see the research project that did MAC & other stuff?)

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