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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z7S8SAGt8blFiFTg@gourry-fedora-PF4VCD3F>
Date: Tue, 18 Feb 2025 11:58:48 -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 Tue, Feb 18, 2025 at 05:04:34PM +0100, Dmitry Vyukov wrote:
> There are two possible scenarios for syscall filtering:
>  - having a trusted/allowed range of PCs, and intercepting everything else
>  - or the opposite: a single untrusted/intercepted range and allowing
>    everything else
> The current implementation only allows the former use case due to
> allowed range wrap-around check. Allow the latter use case as well
> by removing the wrap-around check.
> The latter use case is relevant for any kind of sandboxing scenario,
> or monitoring behavior of a single library. If a program wants to
> intercept syscalls for PC range [START, END) then it needs to call:
> prctl(..., END, -(END-START), ...);

I don't necessarily disagree with the idea, but this sounds like using
the wrong tool for the job.  The purpose of SUD was for emulating
foreign OS system calls of entire programs - not a single library.

The point being that it's very difficult to sandbox an individual
library when you can't ensure it won't allocate resources outside the
monitored bounds (this would be very difficult to guarantee, at least).

If the intent is to load and re-use a single foreign-OS library, this
change seems to be the question of "why not allow multiple ranges?",
and you'd be on your way to reimplementing seccomp or BPF.

~Gregory