[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
    >> [ .. 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

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