linux-hardening - Re: [RFC PATCH v1 0/8] Introduce mseal() syscall

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]

Date: Tue, 17 Oct 2023 13:56:11 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Jeff Xu <jeffxu@...gle.com>
Cc: jeffxu@...omium.org, akpm@...ux-foundation.org, keescook@...omium.org,
	sroettger@...gle.com, jorgelo@...omium.org, groeck@...omium.org,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-mm@...ck.org, jannh@...gle.com, surenb@...gle.com,
	alex.sierra@....com, apopple@...dia.com, aneesh.kumar@...ux.ibm.com,
	axelrasmussen@...gle.com, ben@...adent.org.uk,
	catalin.marinas@....com, david@...hat.com, dwmw@...zon.co.uk,
	ying.huang@...el.com, hughd@...gle.com, joey.gouly@....com,
	corbet@....net, wangkefeng.wang@...wei.com, Liam.Howlett@...cle.com,
	torvalds@...ux-foundation.org, lstoakes@...il.com,
	mawupeng1@...wei.com, linmiaohe@...wei.com, namit@...are.com,
	peterx@...hat.com, peterz@...radead.org, ryan.roberts@....com,
	shr@...kernel.io, vbabka@...e.cz, xiujianfeng@...wei.com,
	yu.ma@...el.com, zhangpeng362@...wei.com, dave.hansen@...el.com,
	luto@...nel.org, linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall

On Tue, Oct 17, 2023 at 01:34:35AM -0700, Jeff Xu wrote:
> > > types: bit mask to specify which syscall to seal, currently they are:
> > > MM_SEAL_MSEAL 0x1
> > > MM_SEAL_MPROTECT 0x2
> > > MM_SEAL_MUNMAP 0x4
> > > MM_SEAL_MMAP 0x8
> > > MM_SEAL_MREMAP 0x10
> >
> > I don't understand why we want this level of granularity.  The OpenBSD
> > and XNU examples just say "This must be immutable*".  For values of
> > immutable that allow downgrading access (eg RW to RO or RX to RO),
> > but not upgrading access (RW->RX, RO->*, RX->RW).
> >
> > > Each bit represents sealing for one specific syscall type, e.g.
> > > MM_SEAL_MPROTECT will deny mprotect syscall. The consideration of bitmask
> > > is that the API is extendable, i.e. when needed, the sealing can be
> > > extended to madvise, mlock, etc. Backward compatibility is also easy.
> >
> > Honestly, it feels too flexible.  Why not just two flags to mprotect()
> > -- PROT_IMMUTABLE and PROT_DOWNGRADABLE.  I can see a use for that --
> > maybe for some things we want to be able to downgrade and for other
> > things, we don't.
> >
> Having a seal type per syscall type helps to add the feature incrementally.
> Applications also know exactly what is sealed.

You're trying to portray a disadvantage as an advantage,  This is the
seccomp disease, only worse because you're trying to deny individual
syscalls instead of building up a list of permitted syscalls.  If we
introduce a new syscall tomorrow which can affect VMAs, we'll then
make it the application's fault for not disabling that new syscall.
That's terrible design!

> I'm not against types such as IMMUTABLE and DOWNGRADEABLE, if we
> can define what it seals precisely. As Jann pointed out, there have
> other scenarios that potentially affect IMMUTABLE. Implementing all thoses
> will take time. And if we missed a case, we could introduce backward
> compatibility issues to the application. Bitmask will solve this nicely, i.e.
> application will need to apply the newly added sealing type explicitly.

It is your job to do this.  You seem to have taken the attitude that you
will give the Chrome team exactly what they asked for instead of trying
to understand their requirements and give them what they need.

And don't send a v2 before discussion of v1 has come to an end.  It
uselessly fragments the discussion.