Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd

[Jann Horn <jannh@google.com>]

On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.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.