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

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]

Date:	Sun, 31 Jul 2016 15:49:42 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Michal Hocko <mhocko@...e.com>,
	Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mateusz Guzik <mguzik@...hat.com>,
	Benjamin Segall <bsegall@...gle.com>,
	John Stultz <john.stultz@...aro.org>,
	Oleg Nesterov <oleg@...hat.com>, matthltc@...ibm.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>, xemul@...tuozzo.com
Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link

On Sun, Jul 31, 2016 at 3:43 PM, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote:
>> Cyrill Gorcunov <gorcunov@...il.com> 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