linux-kernel - Re: [CRIU] [PATCH 1/3] prctl: reduce permissions to change boundaries of data, brk and stack

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: <87lhxc9e1a.fsf@xmission.com>
Date:	Sat, 15 Feb 2014 15:01:05 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Pavel Emelyanov <xemul@...allels.com>,
	Andrew Vagin <avagin@...il.com>,
	Aditya Kali <adityakali@...gle.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	criu@...nvz.org, Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [CRIU] [PATCH 1/3] prctl: reduce permissions to change boundaries of data, brk and stack

Cyrill Gorcunov <gorcunov@...il.com> writes:

> On Fri, Feb 14, 2014 at 12:18:46PM -0800, Eric W. Biederman wrote:
>> >> > 
>> >> > Why can't you have the process of interest do:
>> >> > 	ptrace(PTRACE_ATTACHME);
>> >> > 	execve(executable, args, ...);
>> >> >         
>> >> >         /* Have the ptracer inject the recovery/fixup code */
>> >> > 	    /* Fix up the mostly correct process to look like it has been
>> >> >          * executing for a while.
>> >> >          */
>> >
>> > Erik, it seems I don't understand how it will help us to restore
>> > the mm fields mentioned above?
>> 
>> Because exec is how those mm fields are set when you don't use
>> prctl_set_mm.  So execpt for the stack and the brk limits that
>> will simply result in the values being set to what the usually
>> would be set to.
>
> Yes, all these fields are set up by kernel's elf loader but this
> routine is a way more time consuming than a clone call. But gimme
> some time to examine all possible problems we might have with such
> approach and if there a way to solve them.

Sure.

The really useful observation in all of this is that with exec we have
methods where we allow unprivileged setting of these fields already.  So
it is essentially concerns about applictions being stupid (resource
control) and applications being compromised with evil code and the trace
evidence being hidden that we are trying to protect by limiting changes
to these fields.

So if we can come up with a method that doesn't violate those
invariants, and doesn't lead to massive code maintenance we should be
good.  Reusing exec is just the easiest way to get there.

Eric
--
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/