linux-kernel - Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE

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: <CAG48ez1gnURo_DVSfNk0RLWNbpdbMefNcQXu3as9z2AkNgKaqg@mail.gmail.com>
Date: Fri, 3 Jan 2025 16:13:28 +0100
From: Jann Horn <jannh@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: "Isaac J. Manjarres" <isaacmanjarres@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Jeff Layton <jlayton@...nel.org>, Chuck Lever <chuck.lever@...cle.com>, 
	Alexander Aring <alex.aring@...il.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Vlastimil Babka <vbabka@...e.cz>, Shuah Khan <shuah@...nel.org>, kernel-team@...roid.com, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	Suren Baghdasaryan <surenb@...gle.com>, Kalesh Singh <kaleshsingh@...gle.com>, 
	John Stultz <jstultz@...gle.com>
Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC
 to memfd

On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
> On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
> > +             if (is_exec_sealed(seals)) {
>
> Are we intentionally disallowing a MAP_PRIVATE memfd's mapping's execution?
> I've not tested this scenario so don't know if we somehow disallow this in
> another way but note on write checks we only care about shared mappings.
>
> I mean one could argue that a MAP_PRIVATE situation is the same as copying
> the data into an anon buffer and doing what you want with it, here you
> could argue the same...
>
> So probably we should only care about VM_SHARED?

FWIW I think it doesn't make sense to distinguish between
shared/private mappings here - in the scenario described in the cover
letter, it wouldn't matter that much to an attacker whether the
mapping is shared or private (as long as the VMA contents haven't been
CoWed already). But you're also right that in the scenario described,
an attacker might also be able to create a writable+executable anon
VMA and copy into that, or map another memfd that hasn't been sealed,
or stuff like that. We can block such things - but not by only
providing sealing operations on individual memfds. I think this
instead requires policy that applies at the process level, either
using system-wide SELinux policy or using process sandboxing APIs.