Re: [PATCH] prctl: remove one-shot limitation for changing exe link

From: Andy Lutomirski
Date: Sun Jul 31 2016 - 18:50:11 EST


On Sun, Jul 31, 2016 at 3:43 PM, Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
> On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
>> Cyrill Gorcunov <gorcunov@xxxxxxxxx> writes:
>>
>> > On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
>> > ...
>> >> >>
>> >> >> Also there is a big fat bug in prctl_set_mm_exe_file. It doesn't
>> >> >> validate that the new file is a actually mmaped executable. We would
>> >> >> definitely need that to be fixed before even considering removing the
>> >> >> limit.
>> >> >
>> >> > Could you please elaborate? We check for inode being executable,
>> >> > what else needed?
>> >>
>> >> That the inode is mmaped into the process with executable mappings.
>
> Eric, thanks for clarification. Let me talk from CRIU perspective (because
> the interface came from its need) -- the former executable may no longer
> exist, completely: for such cases in CRIU we simply create that named
> "ghost" files wich are just literally removed upon open. So we simply
> can't mmap the former executable into memory.
>
> Moreover I would really _like_ to not do this check -- the former
> intarface has been done exactly to behave as it does now: don't
> read original file into memory (in criu, when we setup this exelink,
> the original memory of a process already restored so additional
> mmap for every executable is purely waste of time).

Eric, I think I generally disagree with you here. I see no compelling
reason that we shouldn't allow unlimited changes to exe_file so long
as the selected files are executable. (It might make sense to check
that LSM is okay, but even that is a dubious requirement, I think.)
What kind of attack are you worried about?

That being said, we should probably make it so that audit logs
indicate the real executable that was execve'd, but I'd imagine that
this is already the case. But I don't think the original executable
needs to be directly visible in /proc.

--Andy