A deep dive into Linux's new mseal syscall

Not sure if there was much more to it than the thread linked to, but it was basically Linus being Linus. He said stuff that made sense in a pretty blunt fashion.

There were flags proposed that allowed the seal to be ignored.

>So you say "we can't munmap in this *one* place, but all others ignore the sealing".

Later was the spice.

>And dammit, once something is sealed, it is SEALED. None of this crazy "one place honors the sealing, random other places do not".

And later, even spicier, Linus says that seals cannot be ignored and that is non-negotiable. Any further suggestions to ignore a seal via a flag would result in the person being added to Linus' ignore list. (He, of course, said this with some profanities and capitals sprinkled in.)

https://lwn.net/ml/linux-kernel/7071.1697661373@cvs.openbsd....

    From:   Theo de Raadt <deraadt-AT-openbsd.org>
    To:   Jeff Xu <jeffxu-AT-google.com>

    > On Wed, Oct 18, 2023 at 8:17 AM Matthew Wilcox <willy@infradead.org> wrote:
    > >
    > > Let's start with the purpose.  The point of mimmutable/mseal/whatever is
    > > to fix the mapping of an address range to its underlying object, be it
    > > a particular file mapping or anonymous memory.  After the call succeeds,
    > > it must not be possible to make any address in that virtual range point
    > > into any other object.
    > >
    > > The secondary purpose is to lock down permissions on that range.
    > > Possibly to fix them where they are, possibly to allow RW->RO transitions.
    > >
    > > With those purposes in mind, you should be able to deduce for any syscall
    > > or any madvise(), ... whether it should be allowed.
    > >
    > I got it.
    > 
    > IMO: The approaches mimmutable() and mseal() took are different, but
    > we all want to seal the memory from attackers and make the linux
    > application safer.

    I think you are building mseal for chrome, and chrome alone.

    I do not think this will work out for the rest of the application space
    because

    1) it is too complicated
    2) experience with mimmutable() says that applications don't do any of it
    themselves, it is all in execve(), libc initialization, and ld.so.
    You don't strike me as an execve, libc, or ld.so developer.

    From:   Matthew Wilcox <willy-AT-infradead.org>
    To:   Jeff Xu <jeffxu-AT-google.com>

    ...

    Yes, thank you for demonstrating that you have no idea what you need to
    block.

    > It is practical to keep syscall extentable, when the business logic is the same.

    I concur with Theo & Linus.  You don't know what you're doing.  I think
    the underlying idea of mimmutable() is good, but how you've split it up
    and how you've implemented it is terrible.

    ...

This may help a bit: https://lwn.net/Articles/948129/

>Doesn’t that mean it can’t be used for all the memory used by, say, the JS sandbox which would be a very very tempting target?

Multiprocessing is an option here. I think chrome uses it extensively, so that might be the play here. You need separate processes for other stuff anyway, like isolation via namespaces.

Elighten me: what unused/underused safety features x86_64 has that wouldn't require the OS to have some method of using or enabling them? Why do you think mseal isn't warranted and what would be better instead?

mseal digresses from prior memory protection schemes on Linux because it is a syscall tailored specifically for exploit mitigation against remote attackers seeking code execution rather than potentially local ones looking to exfiltrate sensitive secrets in-memory.

If a remote attacker can change the local environment then they must have already broken into your system.

Probably not LD_PRELOAD. It would need to be an imported function in order for LD_PRELOAD to have any effect. A raw syscall would not be interceptable that way.

Discussion about intercepting linux syscalls: https://stackoverflow.com/questions/69859/how-could-i-interc...

But building your own patched kernel that pretends that mseal works would be the simplest way to "disable" that feature. Programs that use mseal could still do sanity checks to see if mseal actually works or not. Then a compromised kernel would need secret ways to disable mseal after it has been applied, to stop the apps from checking for a non-functional mseal.

There's a bunch of ways to override it if you have early control over the process. Another example: ptrace the executable, watch the system calls, and skip over any mseal(2)s.

This system call is meant for a different threat model than "attacker has early access to your process before it started initializing".

You can override the mseal call wrapper but not the syscall itself.

This is an interesting thought so I looked it up and this is how (all?) preload syscall overrides work. You override the wrapper but not the syscalls itself so if you’re doing direct syscalls I don’t think that can be overridden. Technically you could override the syscall function itself maybe?

https://lwn.net/Articles/978010/ says there'll be a glibc tunable

Depends whether the program calls into libc or inlines the syscalls, I imagine. Though you could use other mechanisms like secccomp.

Seems to be OK now:

    int mseal(unsigned long start, size_t len, unsigned long flags)

>OpenBSD has had it since forever.

OpenBSD introduced mimmutable in OpenBSD 7.3, which was released 10/4/2023 (for US people, it would be 4/10/2023), so it isn't "forever".

Meanwhile Linux and FreeBSD has "memfd_create" forever while OpenBSD doesn't have anonymous files and relies on "shm_open".