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: Thu, 19 Oct 2023 09:27:03 +0200
From: Stephen Röttger <>
To: Linus Torvalds <>
Subject: Re: [RFC PATCH v2 7/8] mseal:Check seal flag for mmap(2)

> 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.

These two flags are exactly what we would use in Chrome. I can't think of a
use case for a more fine grained split either.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4005 bytes)

Powered by blists - more mailing lists