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

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

Date: Mon, 22 Jan 2024 08:49:39 -0700
From: "Theo de Raadt" <deraadt@...nbsd.org>
To: 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
Subject: Re: [PATCH v7 0/4] Introduce mseal()

Regarding these pieces

> The PROT_SEAL bit in prot field of mmap(). When present, it marks
> the map sealed since creation.

OpenBSD won't be doing this.  I had PROT_IMMUTABLE as a draft.  In my
research I found basically zero circumstances when you userland does
that.  The most common circumstance is you create a RW mapping, fill it,
and then change to a more restrictve mapping, and lock it.

There are a few regions in the addressspace that can be locked while RW.
For instance, the stack.  But the kernel does that, not userland.  I
found regions where the kernel wants to do this to the address space,
but there is no need to export useless functionality to userland.

OpenBSD now uses this for a high percent of the address space.  It might
be worth re-reading a description of the split of responsibility regarding
who locks different types of memory in a process;
- kernel (the majority, based upon what ELF layout tell us),
- shared library linker (the next majority, dealing with shared
  library mappings and left-overs not determinable at kernel time),
- libc (a small minority, mostly regarding forced mutable objects)
- and the applications themselves (only 1 application today)

    https://lwn.net/Articles/915662/

> The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
> the map as sealable. A map created without MAP_SEALABLE will not support
> sealing, i.e. mseal() will fail.

We definately won't be doing this.  We allow a process to lock any and all
it's memory that isn't locked already, even if it means it is shooting
itself in the foot.

I think you are going to severely hurt the power of this mechanism,
because you won't be able to lock memory that has been allocated by a
different callsite not under your source-code control which lacks the
MAP_SEALABLE flag.  (Which is extremely common with the system-parts of
a process, meaning not just libc but kernel allocated objects).

It may be fine inside a program like chrome, but I expect that flag to make
it harder to use in libc, and it will hinder adoption.