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

[ebiederm@xmission.com (Eric W. Biederman)]

Cyrill Gorcunov <gorcunov@gmail.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