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

    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

    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

    > > 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.. ;]



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.023 / U:75.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site