linux-kernel - Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120313062625.GA1912@moon>
Date:	Tue, 13 Mar 2012 10:26:25 +0400
From:	Cyrill Gorcunov <gorcunov@...nvz.org>
To:	Matt Helsley <matthltc@...ibm.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Kees Cook <keescook@...omium.org>, Tejun Heo <tj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [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.

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