linux-kernel - Re: [PATCH] prctl: allow prctl_set_mm_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: <C96F1571-3E1B-44BB-B505-6C25F43CABA4@icloud.com>
Date: Wed, 28 Aug 2024 09:40:47 -0700
From: tblodt@...oud.com
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: linux-kernel@...r.kernel.org,
 Ryan Houdek <sonicadvance1@...il.com>,
 "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
 David Hildenbrand <david@...hat.com>,
 Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] prctl: allow prctl_set_mm_exe_file without unmapping old
 exe

> On Aug 28, 2024, at 6:32 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> 
> One of my original concerns is that allowing changing the /proc/self/exe
> has the potential to make /proc/self/exe unreliable and specifically it
> has the potential for a rouge program to hide itself by setting a false
> /proc/self/exe.
> 
> That is part of the reason for the red tape.
> 
> Maybe I am wrong but I am concerned that your change may be making it
> too easy to change /proc/self/exe, and would too easily allow setting a
> false /proc/self/exe.
> 
> So it may make better sense to have a special case for interpreters,
> so we don't have to worry about people setting a false /proc/self/exe.

After sending this it was pointed out to me that the ioctl actually requires CAP_SYS_RESOURCE. On one hand, this resolves the problem of a rogue program - it would already have to be privileged. On the other hand, this makes it that much harder for FEX to use because it would have to rely on getting setcapped during installation, and we'd like to be able to make use of sandboxed binfmt_misc[1] to install FEX in an unprivileged user namespace.

I would prefer resurrecting the last proposal for a special case for interpreters in some form, given the above and also that the previous proposal would always allow you to see the interpreter from a different /proc file, *somewhat* reducing the security concerns...

A thought: Being registered in binfmt_misc already means you're privileged, so it would seem to be ok to allow the interpreter this extra privilege. In the case of unprivileged/sandboxed binfmt_misc, it would be sufficient to only change the view of /proc/self/exe for processes in the user namespace with the interpreter registered. But is it ok for a view of procfs to be dependent on the user namespace and not just the pid namespace..? is there prior art?

> Looking at the code I am a bit perplexed at the moment as I don't see
> a check currently to ensure the new exe_file is actually mapped.

Yes - since the check was just to avoid confusion with num_exe_file_vmas, not for any serious reason, it seems...

> 
> ...
> 
> Beyond that your change reduces replace_mm_exe_file to set_mm_exe_file
> so it would probably make sense to combine the two of them if you
> are going to go this far.
> 
> Eric

[1]: https://lore.kernel.org/all/20211216112659.310979-2-brauner@kernel.org/