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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.171 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site