Messages in this thread | | | Date | Sun, 19 Apr 1998 23:25:50 -0700 | From | Andrew Morgan <> | Subject | Re: [patch 2.1.97] more capabilities support |
| |
Albert D. Cahalan writes: > > 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.
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.
Also note that, in the first example, the fE is not needed. Since cleanme.tool is aware of the notion of capabilities, it can raise its own capabilities with a system call and not rely on the fE to be set.
Note too that pI' differs in the two cases. This means that anything executed by 'cleaner-running-cleanme.tool' in the strict capability model will by default fail to get a chance to inherit the capability [this is a feature]. Should this process want to pass this capability on, it can do so by raising its pI' capability before next calling sys_exec().
The golden rule is that a process has potential power over a capability if its corresponding 'pP' is set. This gives it the power to raise both its pE (to be able to use the capability) and pI (to be able to pass it on accross an exec) capabilities with a system call. However, the point is that it has to _choose_ to do either/both of these.
> > 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 going to put all this in the documentation. I strongly suspect other people will find it handy.. ;]
Cheers
Andrew
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |