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]
Date: Tue, 17 Oct 2023 10:43:39 -0700
From: Linus Torvalds <>
Subject: Re: [RFC PATCH v2 7/8] mseal:Check seal flag for mmap(2)

On Tue, 17 Oct 2023 at 10:04, Linus Torvalds
<> wrote:
> Honestly, there is only two kinds of sealing that makes sense:
>  - you cannot change the permissions of some area
>  - you cannot unmap an area

Actually, I guess at least theoretically, there could be three different things:

 - you cannot move an area

although I do think that maybe just saying "you cannot unmap" might
also include "you cannot move".

But I guess it depends on whether you feel it's the virtual _address_
you are protecting, or whether it's the concept of mapping something.

I personally think that from a security perspective, what you want to
protect is a particular address. That implies that "seal from
unmapping" would thus also include "you can't move this area

But at least conceptually, splitting "unmap" and "move" apart might
make some sense. I would like to hear a practical reason for it,

Without that practical reason, I think the only two sane sealing operations are:

 - SEAL_MUNMAP: "don't allow this mapping address to go away"

   IOW no unmap, no shrinking, no moving mremap

 - SEAL_MPROTECT: "don't allow any mapping permission changes"

Again, that permission case might end up being "don't allow
_additional_ permissions" and "don't allow taking permissions away".
Or it could be split by operation (ie "don't allow permission changes
to writability / readability / executability respectively").

I suspect there isn't a real-life example of splitting the
SEAL_MPROTECT (the same way I doubt there's a real-life example for
splitting the UNMAP into "unmap vs move"), so unless there is some
real reason, I'd keep the sealing minimal and to just those two flags.

We could always add more flags later, if there is a real use case
(IOW, if we start with "don't allow any permission changes", we could
add a flag later that just says "don't allow writability changes").


Powered by blists - more mailing lists