linux-kernel - Re: [RFC PATCH v5 0/7] mseal 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: <c597fdcd4356636fc3163a46da32fc5d6c17aed9.camel@sipsolutions.net>
Date: Wed, 12 Feb 2025 15:08:51 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Pedro Falcato
	 <pedro.falcato@...il.com>
Cc: jeffxu@...omium.org, akpm@...ux-foundation.org, keescook@...omium.org, 
	jannh@...gle.com, torvalds@...ux-foundation.org, vbabka@...e.cz, 
	Liam.Howlett@...cle.com, adhemerval.zanella@...aro.org, oleg@...hat.com, 
	avagin@...il.com, benjamin@...solutions.net, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org, linux-mm@...ck.org, jorgelo@...omium.org, 
	sroettger@...gle.com, hch@....de, ojeda@...nel.org, 
	thomas.weissschuh@...utronix.de, adobriyan@...il.com, hca@...ux.ibm.com, 
	willy@...radead.org, anna-maria@...utronix.de, mark.rutland@....com, 
	linus.walleij@...aro.org, Jason@...c4.com, deller@....de,
 rdunlap@...radead.org, 	davem@...emloft.net, peterx@...hat.com,
 f.fainelli@...il.com, gerg@...nel.org, 	dave.hansen@...ux.intel.com,
 mingo@...nel.org, ardb@...nel.org, 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, 
	aleksandr.mikhalitsyn@...onical.com, mike.rapoport@...il.com
Subject: Re: [RFC PATCH v5 0/7] mseal system mappings

On Wed, 2025-02-12 at 14:01 +0000, Lorenzo Stoakes wrote:
> Thanks, yeah that's a good point, it would have to be implemented as a
> personality or something similar otherwise you're essentially relying on
> 'unsealing' which can't be permitted.
> 
> I'm not sure how useful that'd be for the likes of rr though. But I suppose
> if it makes everything exec'd by a child inherit it then maybe that works
> for a debugging session etc.?

For whatever that's worth, ARCH=um should not need 'unsealing' or 'not
sealing' it for *itself*, but rather only for the *children* it starts,
which are for the userspace processes inside of it. Which I suppose
could actually start without a VDSO in the first place, but I don't
think that's possible now?

Which I'll note should not have access to the host, so in a way this
outer security feature (sealing) breaks the inner ARCH=um security, I
think.

johannes