Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3

[Cyrill Gorcunov]

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.

	Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/