linux-kernel - Re: [PATCH 1/3] syscall_user_dispatch: Allow allowed range wrap-around

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] [day] [month] [year] [list]

Message-ID: <Z7XczcHC-6RcBqzX@gourry-fedora-PF4VCD3F>
Date: Wed, 19 Feb 2025 08:29:49 -0500
From: Gregory Price <gourry@...rry.net>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: krisman@...labora.com, tglx@...utronix.de, luto@...nel.org,
	peterz@...radead.org, keescook@...omium.org,
	gregory.price@...verge.com, Marco Elver <elver@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] syscall_user_dispatch: Allow allowed range
 wrap-around

On Wed, Feb 19, 2025 at 09:54:28AM +0100, Dmitry Vyukov wrote:
> On Tue, 18 Feb 2025 at 19:00, Gregory Price <gourry@...rry.net> wrote:
> >
> > No.  SUD's purpose is to catch foreign-OS syscall execution.
> 
> My understanding is that aiming at concrete end problems is not the
> kernel approach and design philosophy. Instead it aims at providing
> flexible _primitives_ that can be used to solve various end problems.
> It's like you are not selling pencils to draw trees, instead you just
> sell good pencils.

Fair point, apologies for being blunt here.

Mostly i'm concerned at the use of SUD for "sandboxing" when it is not
itself a sufficient isolation mechanism for this - it's far too easy to
bypass and has basically no guardrails to enforce it.

But it's not my place to say how to use features in userland (also I've
written a lib-c interposer for fun with SUD anyway so *shrug*).

> > Like I said, I don't necessarily disagree with the change, just a bit
> > concerned about the direction this takes SUD.  It's not a sufficient
> > interface to isolate the behavior of a single library, and this change
> > naturally begs the question "If we do this, why not implement an entire
> > multi-range filtering system? Why stop at one range?"
> 
> That's a harder question. I think we don't need to answer it right
> now. We can just consider this proposal in isolation. This is where we
> stop now.
> It preserves all of the existing uses intact + allows more cases with
> a trivial code change (actually deleting code).

You may also want to update

  Documentation/admin-guide/syscall-user-dispatch.rst

to have some examples w/ wrap-around, since most people would not even
think about this as a possibility.

(also, i'm not sure if you've sent a cover letter or not, but lore seems
 to suggest it is missing - and it did not show up in my box)

~Gregory