lkml.org 
[lkml]   [2009]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: disablenetwork facility. (v4)
    Quoting Eric W. Biederman (ebiederm@xmission.com):
    > "Serge E. Hallyn" <serue@us.ibm.com> writes:
    >
    > > Quoting Eric W. Biederman (ebiederm@xmission.com):
    > >> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
    > >>
    > >> >> > Execute != read. The executable file may contain secrets which must not
    > >> >> > be available to the user running the setuid program. If you fail the
    > >> >> > setuid, the user will be able to ptrace() and then the secret is
    > >> >> > revealed.
    > >> >> >
    > >> >> > It's amazing how many security holes appear from what seems like a very
    > >> >> > simple request.
    > >> >>
    > >> >> Do we have a security hole in nosuid mount option?
    > >> >> Can someone write a patch to fix it?
    > >> >
    > >> > If a setuid app can read a key when its erroneously not set setuid then
    > >> > the user can read it too.
    > >> >
    > >> > Anything you can do with ptrace you can do yourself !
    > >>
    > >> Now that I think about it this is really something completely separate
    > >> from setuid. This is about being able to read the text segment with
    > >> ptrace when you on have execute permissions on the file.
    > >>
    > >> I just skimmed through fs/exec.c and we set the undumpable process
    > >> flag in that case so ptrace should not work in that case.
    > >
    > > And in fact you can't do a new ptrace_attach, but if you're already
    > > tracing the task when it execs the unreadable-but-executable file,
    > > then the ptrace can continue.
    > >
    > > Just looking at the code, it appears 2.2 was the same way (though I
    > > could be missing where it used to enforce that).
    > >
    > > So, is that intended? What exactly would we do about it if not?
    > > Just refuse exec of a unreadable-but-executable file if we're
    > > being traced?
    >
    > In common cap we drop the new capabilities if we are being ptraced.
    > Look for brm->unsafe.

    Yes - that isn't the issue. The issue is with a file to which
    we have execute permission but not read. If user hallyn has two
    terminals open, and terminal one does ./foo then terminal two
    cannot do strace -f -p `pidof foo`. But user hallyn can do
    strace -f -p ./foo and succeed.

    So we refuse ptrace_attach to an existing process with dumpable
    turned off, but a pre-existing ptrace attach isn't affected by
    executing a file which causes dumpable to be unset.

    It goes back to finding a way to figure out what is inside the
    file when the installer obviously thought we shouldn't be able
    to read the file.

    Do we care? <shrug>

    -serge


    \
     
     \ /
      Last update: 2009-12-30 04:53    [W:0.027 / U:30.644 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site