lkml.org 
[lkml]   [2012]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Capabilities still can't be inherited by normal programs
    On 12/5/2012 2:20 PM, Serge Hallyn wrote:
    > Quoting Andy Lutomirski (luto@amacapital.net):
    >> On Wed, Dec 5, 2012 at 1:05 PM, Serge Hallyn <serge.hallyn@canonical.com> wrote:
    >>> Quoting Andy Lutomirski (luto@amacapital.net):
    >>>> On Tue, Dec 4, 2012 at 5:54 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
    >>>>> Quoting Andy Lutomirski (luto@amacapital.net):
    >>>>>>>> d) If I really wanted, I could emulate execve without actually doing
    >>>>>>>> execve, and capabilities would be inherited.
    >>>>>>> If you could modify the executable properties of the binary that has
    >>>>>>> the privilege to wield a privilege then you are either exploiting an
    >>>>>>> app bug, or doing something the privileged binary has been trusted to
    >>>>>>> do.
    >>>>>> That's not what I mean. I would:
    >>>>>>
    >>>>>> fork()
    >>>>>> munmap everything
    >>>>>> mmap ld.so
    >>>>>> set up a fake initial stack and the right fd or mapping or whatever
    >>>>>> just to ld-linux.so
    >>>>>>
    >>>>>> That's almost execve, and privilege inheritance works.
    >>>>> But of course that is why you only want to fill fI on programs you trust
    >>>>> not to do that. What you are arguing is that you want to give fI on
    >>>>> programs you don't trust anyway, and so heck why not just give it on
    >>>>> everything.
    >>>>>
    >>>> Huh? I'd set fP on a program I expect to do *exactly* that (or use
    >>>> actual in-kernel capability inheritance, which I would find vastly
    >>>> more pleasant). If I give a program a capability (via fP or fI & pI),
    >>>> then I had better trust it not to abuse that capability. Having it
    >>>> pass that capability on to a child helper process would be just fine
    >>>> with me *because it already has that capability*.
    >>>>
    >>>> The problem with the current inheritance mechanism is that it's very
    >>>> difficult to understand what it means for an fI bit or a pI bit to be
    >>>> set. Saying "set a pI bit using pam if you want to grant permission
    >>>> to that user to run a particular program with fI set" is crap -- it
    >>>> only works if there is exactly one binary on the system with that bit
    >>>> set. In any case, a different administrator or package might use it
    >>>> for something different.
    >>>>
    >>>> Suppose I use the (apparently) current suggested approach: I install a
    >>>> fI=cap_net_raw copy of tcpdump somewhere. Then I write a helper that
    >>>> has fP=cap_new_raw and invokes that copy of tcpdump after appropriate
    >>>> validation of parameters. All is well.
    >>> Since you're writing a special helper, you can surely have it validate
    >>> the userid and make it so the calling user doesn't have to have
    >>> cap_net_raw in pI?
    >> I can and did.
    > Oh, oops, I mis-understood what you meant was the problem.
    >
    > Yup, that is a real limitation.
    >
    > Yes, with the posix file caps you will be disappointed unless you see
    > pI=X as "this user may run any program which is Inh-trusted with X" and
    > fI=X as "this program may be run with X by any user Inh-trusted with X".
    >
    > It almost makes me want to say that there should be an execve-analogue
    > to prctl(PR_SET_KEEPCAPS), which says caps will remain unchanged for one
    > execve. Or perhaps an intermediate securebits state between
    > !SECBIT_NOROOT and SECBIT_NOROOT, which automatically transitions after
    > the first execve to SECBIT_NOROOT.
    >
    >> The mere presence of a cap_net_raw+i tcpdump binary is more or less
    >> equivalent to saying that users with cap_net_raw in pI can capture
    >> packets. I've just prevented pI=cap_net_raw from meaning anything
    >> less than "can capture packets". So I think we should bite the bullet
    >> and just let programs opt in (via some appropriately careful
    >> mechanism) to real capability inheritance.
    > By real you mean more precise. I think it'd be very interesting to get
    > together with Markku and learn more from the N9 experiment!
    >
    > Markku, are there any post-mortem analysis papers we can read for
    > starters? Andy would not be trying to restrict root in general, so
    > the ramification you cited may not necessarily be relevant.
    >
    > -serge

    http://wt.tuxomania.net/publications/posix.1e/download.html

    Everyone should read the capabilities rationale. It answers most
    of the questions on this thread, and a bunch more. The capabilities
    mechanism has to support what are currently setuid-root programs
    without change and allow for new programs that use the mechanism
    wisely and fully.


    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    >



    \
     
     \ /
      Last update: 2012-12-07 05:01    [W:4.809 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site