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: <CABi2SkXYjq0ACYkFf3e35DoOJP6d3TEpLEU_RCTmNLHQ_YJq6g@mail.gmail.com>
Date: Mon, 16 Dec 2024 10:35:06 -0800
From: Jeff Xu <jeffxu@...omium.org>
To: Andrei Vagin <avagin@...il.com>
Cc: 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, 
	Dmitry Safonov <0x7f454c46@...il.com>, Mike Rapoport <mike.rapoport@...il.com>, 
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>, Andrei Vagin <avagin@...gle.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

Hi Andrei

On Thu, Dec 12, 2024 at 10:33 PM Andrei Vagin <avagin@...il.com> wrote:
>
> On Wed, Dec 11, 2024 at 2:47 PM Jeff Xu <jeffxu@...omium.org> wrote:
> >
> > Hi Andrei
> >
> > Thanks for your email.
> > I was hoping to get some feedback from CRIU devs, and happy to see you
> > reaching out..
> >
> ...
> > I have been thinking of other alternatives, but those would require
> > more understanding on CRIU use cases.
> > One of my questions is: Would CRIU target an individual process? or
> > entire systems?
>
> It targets individual processes that have been forked from the main
> CRIU process.
>
> >
> > If it is an individual process, we could use prctl to opt-in/opt-out
> > certain processes. There could be two alternatives.
> > 1> Opt-in solution: process must set prctl.seal_criu_mapping, this
> > needs to be set before execve() because sealing is applied at execve()
> > call.
> > 2> opt-out solution: The system will by default seal all of the system
> > mappings, but individual processes can opt-out by setting
> > prctl.not_seal_criu_mappings. This also needs to be set before
> > execve() call.
>
> I like the idea and I think the opt-out solution should work for CRIU.
> CRIU will be able to call this prctl and re-execute itself.
>
Great! Let's iterate on the opt-out solution then.

> Let me give you a bit of context on how CRIU works. When CRIU restores
> processes, it recreates a process tree by forking itself. Afterwards, it
> restores all mappings in each process but doesn't put them to proper
> addresses. After that, each process unmaps CRIU mappings from its address
> space and remaps its restored mappings to the proper addresses. So CRIU should
> be able to move system mappings and seal them if they have been sealed before
> dump.
Thanks for the context.

> BTW, It isn't just about CRIU. gVisor and maybe some other sandbox solutions
> will be affected by this change too. gVisor uses stub-processes to represent
> guest address spaces. In a stub process, it unmaps all system mappings.
>
> >
> > For both cases, we will want to identify what type of mapping CRIU
> > cares about, i.e. maybe CRIU doesn't care about uprobe and vsyscall ?
> > and only care about vdso/vvar/sigpage ?
>
> As for now, it handles only vdso/vvar/sigpage mappings. It doesn't care
> about vsyscall because it is always mapped to the fixed address.
>
Given this understanding that CRIU intends to replace the current
process's vdso/vvar with that of the restored process, and therefore
doesn't want the parent CRIU process to seal the vdso/vvar, a prctl
opt-out  for vdso/vvar is reasonable path going forward.

The sigpage mapping also should be included in this opt-out, for the
same reason as vdso/vvar,  it is created by the
arch_setup_additional_pages() call during execve().

However, the uprobe mapping shouldn't be included by this opt-out, as
it is not created by arch_setup_additional_pages() during execveat().
CRIU should simply restore it from the restored process, if present.

vsyscall, which is created when the system boots, and maps to a fixed
virtual address and page, shouldn't be included by this opt-out.

So I'm proposing to opt-out vdso/vvar/sigpage with a new prctl:
disable_mseal_criu_system_mappings = true/false
What do you think ?

> gVisor should be able to unmap all system mappings from a process
> address space.
>
Do you think this opt-out solution will work for gVisor too ?

Thanks
-Jeff


> Thanks,
> Andrei