linux-kernel - Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <f880562e-9521-4270-82e2-c6fb14dc853a@app.fastmail.com>
Date: Fri, 24 May 2024 16:28:50 +0200
From: "David Rheinsberg" <david@...dahead.eu>
To: "Jeff Xu" <jeffxu@...gle.com>, "Aleksa Sarai" <cyphar@...har.com>
Cc: Barnabás Pőcze <pobrn@...tonmail.com>,
 "Andrew Morton" <akpm@...ux-foundation.org>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 dmitry.torokhov@...il.com, "Daniel Verkamp" <dverkamp@...omium.org>,
 hughd@...gle.com, jorgelo@...omium.org, skhan@...uxfoundation.org,
 "Kees Cook" <keescook@...omium.org>
Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING`

Hi

On Thu, May 23, 2024, at 6:55 PM, Jeff Xu wrote:
> On Thu, May 23, 2024 at 9:20 AM Jeff Xu <jeffxu@...gle.com> wrote:
>> On Thu, May 23, 2024 at 1:24 AM David Rheinsberg <david@...dahead.eu> wrote:
>> > We asked for exactly this fix before, so I very much support this. Our test-suite in `dbus-broker` merely verifies what the current kernel behavior is (just like the kernel selftests). I am certainly ok if the kernel breaks it. I will gladly adapt the test-suite.
>> >
> memfd is by default not sealable, and file is by default sealable,
> right ? that makes the memfd  semantics different from other objects
> in linux.
> I wonder what is the original reason to have memfd  this way?

shmem-files are *not* sealable by default. This design was followed for backward compatibility reasons, since shmem-files predate sealing and silently enabling sealing on all shmem-files would have broken existing users (see shmem.c which initializes seals to F_SEAL_SEAL).

I am not sure what you mean with "makes [memfd] semantics different from other objects in linux". Can you elaborate?

Since `memfd_create` was introduced at the same time as shmem-sealing, it could certainly have enabled sealing by default. Not sure whether this would be preferable, though.

> Another solution is to change memfd to be by-default sealable,
> although that will be an api change, but what side effect  will it be
> ?
> If we are worried about the memfd being sealed by an attacker, the
> malicious code could also overwrite the content since memfd is not
> sealed.

You cannot change the default-seals retrospectively. There are existing shmem-users that share file-descriptors and *expect* the other party to be able to override data, but do *not* expect the other party to be able to apply seals. Note that these models explicitly *want* shared, writable access to the buffer (e.g., render-client shares a buffer with the display server for scanout), so just because you can *write* to a shmem-file does not mean that sharing is unsafe (e.g., using SIGBUS+mmap can safely deal with page-faults).

Thanks
David