Re: [RFC PATCH v5 0/7] mseal system mappings

[Jeff Xu <jeffxu@chromium.org>]

On Tue, Feb 18, 2025 at 3:18 PM Pedro Falcato <pedro.falcato@gmail.com> wrote:
> The problem with something like prctl is that we either indirectly
> provide some kind of limited form of munseal, or we require some sort
> of handover (like personality(2) + execve(2)), which both sound like a
> huge PITA and still don't solve any of our backwards compat issues...
> all binaries would need to be patched with this
> prctl/personality()/whatever call, and old ones wouldn't work.
>
SECBIT (such as AT_EXECVE_CHECK) can be locked, which provides a
strong security guarantee.

> The semantics behind GNU_PROPERTY_MEMORY_SEAL are unclear to me (maybe
> the toolchain folks could shed some light?), but it sounds like it'd
> fit perfectly.
> I suspect we probably want to parse this on the kernel's side anyway
> (to seal the main program/interp's segments)[1], then extending them
> to the kernel system mappings should be somewhat trivial...
> I don't think we'll ever get a program that can't cope with sealing
> the system mappings but can cope with sealing itself (and if we do, we
> just won't seal the entire thing and that's _okay_).
>
> Deploying mseal-ready programs could then be done in a phased way by
> distros. e.g chromeOS and android could simply enable the
> corresponding linker option in LDFLAGS and let it rip. Other more
> mainstream distros could obviously take a little longer or test/deploy
> this on all programs not named gVisor and/or after CRIU is okay with
> all of this. We then might not need a user-configurable CONFIG_ (only
> an arch HAS_SYSTEM_MAPPINGS_MSEAL or whatever), nor a sysctl, and
> everyone is happy.
>
> I glanced through libc-alpha again and it seems like the glibc folks
> also seem to have reached the same idea, but I'd love to hear from
> Adhemerval.
>
> Am I missing anything?
>
I'm hesitant to rely on HAS_SYSTEM_MAPPINGS_MSEAL in the kernel for
special mappings.

Think this way: some apps don't want vdso, but the kernel creates it
anyway,  those apps were forced to unmap or remap them.

If the kernel should take a new dependency on the elf header, a better
approach is adding a bit in the elf header to indicate "not-creating
vdso".  This would solve problems for those apps that want to unmap
vdso.

CRIU would need more than this new bit, i.e.  an ability to create
vdso on demand. Currently, during restore workflow, CRIU remaps the
vdso created by the current kernel (can't use vdso from the back-up,
because vdso is tied to the kernel version), and the remapping address
must be the same address  as the backed-up process, to avoid
symbol-relocation. Kernel can provide a new functionality to create
this vdso mapping as desired by CRIU.

Then the vdso can be sealed from creation in all cases, this is the
most secure approach. And the kernel also doesn't need that code to
remap/unmap vdso - that is also cleaner IMO.

Thanks.
-Jeff


>
> [1] we should probably nail this responsibility handover down before
> glibc msealing (or bionic) makes it to a release. It'd probably be a
> little nicer if we could mseal these segments from the kernel instead
> of forcing the libc to take care of this, now that we have this
> property.
>
> --
> Pedro