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

lists.openwall.net		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]

Message-ID: <CANaxB-zosDQ_0wk3TaYyP9wZ9bVK8jU4miPgz8cqNNekGg6_sQ@mail.gmail.com>
Date: Thu, 2 Jan 2025 11:15:51 -0800
From: Andrei Vagin <avagin@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: jeffxu@...omium.org, akpm@...ux-foundation.org, keescook@...omium.org, 
	jannh@...gle.com, torvalds@...ux-foundation.org, 
	adhemerval.zanella@...aro.org, oleg@...hat.com, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org, linux-mm@...ck.org, jorgelo@...omium.org, 
	sroettger@...gle.com, ojeda@...nel.org, adobriyan@...il.com, 
	anna-maria@...utronix.de, mark.rutland@....com, linus.walleij@...aro.org, 
	Jason@...c4.com, deller@....de, rdunlap@...radead.org, davem@...emloft.net, 
	hch@....de, peterx@...hat.com, hca@...ux.ibm.com, f.fainelli@...il.com, 
	gerg@...nel.org, dave.hansen@...ux.intel.com, mingo@...nel.org, 
	ardb@...nel.org, Liam.Howlett@...cle.com, mhocko@...e.com, 
	42.hyeyoo@...il.com, peterz@...radead.org, ardb@...gle.com, enh@...gle.com, 
	rientjes@...gle.com, groeck@...omium.org, mpe@...erman.id.au, 
	Vlastimil Babka <vbabka@...e.cz>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	Dmitry Safonov <0x7f454c46@...il.com>, Mike Rapoport <mike.rapoport@...il.com>, 
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

On Tue, Dec 17, 2024 at 2:18 PM Kees Cook <kees@...nel.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