linux-hardening - Re: [PATCH v7 0/4] Introduce mseal()

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] [day] [month] [year] [list]

Date: Wed, 31 Jan 2024 13:51:42 -0700
From: Jonathan Corbet <corbet@....net>
To: Jeff Xu <jeffxu@...omium.org>
Cc: akpm@...ux-foundation.org, keescook@...omium.org, jannh@...gle.com,
 sroettger@...gle.com, willy@...radead.org, gregkh@...uxfoundation.org,
 torvalds@...ux-foundation.org, usama.anjum@...labora.com,
 rdunlap@...radead.org, jeffxu@...gle.com, jorgelo@...omium.org,
 groeck@...omium.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
 pedro.falcato@...il.com, dave.hansen@...el.com,
 linux-hardening@...r.kernel.org, deraadt@...nbsd.org
Subject: Re: [PATCH v7 0/4] Introduce mseal()

Jeff Xu <jeffxu@...omium.org> writes:

> On Mon, Jan 29, 2024 at 2:37 PM Jonathan Corbet <corbet@....net> wrote:
>>
>> jeffxu@...omium.org writes:
>>
>> > Although the initial version of this patch series is targeting the
>> > Chrome browser as its first user, it became evident during upstream
>> > discussions that we would also want to ensure that the patch set
>> > eventually is a complete solution for memory sealing and compatible
>> > with other use cases. The specific scenario currently in mind is
>> > glibc's use case of loading and sealing ELF executables. To this end,
>> > Stephen is working on a change to glibc to add sealing support to the
>> > dynamic linker, which will seal all non-writable segments at startup.
>> > Once this work is completed, all applications will be able to
>> > automatically benefit from these new protections.
>>
>> Is this work posted somewhere?  Having a second - and more generally
>> useful - user for this API would do a lot to show that the design is, in
>> fact, right and useful beyond the Chrome browser.
>>
> Stephen conducted a PoC last year, it will be published once it is complete.
> We're super excited about introducing this as a general safety measure
> for all of Linux!

We're excited too, something like mseal() seems like a good thing to
have.  My point, though, is that it would be good to see this second
(and more general) user of the API *before* merging it.  As others have
noted, once mseal() is in a released kernel, it will be difficult to
change if adjustments turn out to be necessary.

Thanks,

jon