[lkml]   [2012]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3
    On Mon, Mar 12, 2012 at 07:45:11PM -0700, Matt Helsley wrote:
    > >
    > > Indeed. But I think any change will mean compatibility broken, programs
    > > may rely on one-shot or multi-shot behaviour. So I personally vote
    > > for more flexible approach here.
    > Very true. In fact thinking about this prctl a bit more makes me more certain
    > that one-shot is better and it ought to stay that way forever. The
    > flexibility to change the /proc/pid/exe symlink could be yet another
    > way for malicious code to obscure a compromised program and
    > masquerade as a benign process. That's a problem inherent in this prctl
    > whether its one-shot or multi-shot. However, if you use the one-shot
    > approach then a security-concious program can use this prctl once
    > during its early initialization to ensure the prctl cannot later be abused
    > for this purpose.

    Hi Matt,

    well, sure our tool can live with one-shot approach (and I'll update it)
    but not that only program with CAP_RESOURCE granted can do that, ie it's
    not any arbitrary program in a system.

    > > names -- how would he know if a program did change own /proc/pid/exe
    > > at all? Note it's not that important how many times the symlink was
    > > changed there is simply no way to find out if it was changed at all,
    > > and actually from my POV it's a win for transparent c/r, that was
    > > all the idea.
    > I am quite aware of the c/r use for this prctl :). However I also
    > wonder if there aren't serious malicious uses of it. I'm not saying the
    > symlink has to be perfectly accurate at all times, but it's easy and
    > reasonable to make it much harder to abuse this particular prctl for
    > malicious purposes by making it one-shot.

    ok, convinced, I'll update the patch ;)

    > With this patch -- especially the multi-shot form -- the symlink will
    > be entirely under the control of (potentially untrusted) userspace code
    > and the admin is totally at the mercy of the userspace code. In
    > single-shot form programs could use the prctl() to ensure the symlink
    > could not be changed later -- the restart tool would be the only program
    > that would need to ensure that prctl() had not been used since the last
    > exec*().
    > If we're going to let userspace do arbitrary things to the symlink I can't
    > help but wonder why we can't skip the prctl() altogether and just enable
    > MAP_EXECUTABLE in mmap().

    Well, hard to tell from my side. At moment I don't see problem in allowing
    MAP_EXECUTABLE in mmap, but -mm guys help needed. I'm sure there were a reason
    why it's not allowed.


     \ /
      Last update: 2012-03-13 07:29    [W:0.023 / U:30.608 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site