Re: [PATCH v4 1/1] exec: seal system mappings

[Andrei Vagin <avagin@gmail.com>]

On Tue, Dec 17, 2024 at 2:18 PM Kees Cook <kees@kernel.org> wrote:
>
....
> Also from discussions it sounds like there may need to be even finer-gain
> control, likely via prctl, for dealing with the CRIU case. The proposal
> is to provide an opt-out prctl with CAP_CHECKPOINT_RESTORE? I think this
> is reasonable and lets this all work without a new CONFIG. I imagine it
> would look like:
>
> criu process (which has CAP_CHECKPOINT_RESTORE):

Hi Kees,

Sorry for the delay, I've been out of network for the last two weeks.

Overall, this approach looks good to me. However, I think the opt-out prctl
shouldn't depend on CAP_CHECKPOINT_RESTORE. There are other use cases
besides CRIU where we need to unmap or move system mappings.
For example, gVisor uses stub processes to represent guest address spaces.
gVisor unmaps all system mappings (like vdso, vvar, etc) from stub processes.

>         - prctl(GET_MSEAL_SYSTEM_MAPPINGS)
>         - if set:
>                 - remember we need to mseal mappings
>                 - prctl(SET_MSEAL_SYSTEM_MAPPINGS, 0)
>                 - re-exec with --mseal-system-mappings (or something)
>         - perform the "fork a tree to restore" work
>         - in each child, move around all the mappings
>                 - if we need to mseal mappings:
>                         - prctl(SET_MSEAL_SYSTEM_MAPPINGS, 1)
>                         - mseal each system mapping
>                 - eventually drop CAP_CHECKPOINT_RESTORE
>                 - become the restored process
>

Thanks,
Andrei