linux-kernel - Re: [PATCH v3 0/2] seccomp: pass uretprobe system call through seccomp

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: <CAHsH6GtiwCGJevfkE5=VzzuQcusKp-ugnRD+AD+5a+8kqOGyZA@mail.gmail.com>
Date: Fri, 7 Feb 2025 08:20:43 -0800
From: Eyal Birger <eyal.birger@...il.com>
To: Jann Horn <jannh@...gle.com>, jolsa@...nel.org
Cc: kees@...nel.org, luto@...capital.net, wad@...omium.org, oleg@...hat.com, 
	mhiramat@...nel.org, andrii@...nel.org, alexei.starovoitov@...il.com, 
	olsajiri@...il.com, cyphar@...har.com, songliubraving@...com, yhs@...com, 
	john.fastabend@...il.com, peterz@...radead.org, tglx@...utronix.de, 
	bp@...en8.de, daniel@...earbox.net, ast@...nel.org, andrii.nakryiko@...il.com, 
	rostedt@...dmis.org, rafi@....io, shmulik.ladkani@...il.com, 
	bpf@...r.kernel.org, linux-api@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, x86@...nel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/2] seccomp: pass uretprobe system call through seccomp

Hi,

On Fri, Feb 7, 2025 at 7:27 AM Jann Horn <jannh@...gle.com> wrote:
>
> On Sun, Feb 2, 2025 at 5:29 PM Eyal Birger <eyal.birger@...il.com> wrote:
> > uretprobe(2) is an performance enhancement system call added to improve
> > uretprobes on x86_64.
> >
> > Confinement environments such as Docker are not aware of this new system
> > call and kill confined processes when uretprobes are attached to them.
>
> FYI, you might have similar issues with Syscall User Dispatch
> (https://docs.kernel.org/admin-guide/syscall-user-dispatch.html) and
> potentially also with ptrace-based sandboxes, depending on what kinda
> processes you inject uprobes into. For Syscall User Dispatch, there is
> already precedent for a bypass based on instruction pointer (see
> syscall_user_dispatch()).

Thanks. This is interesting.

Do you know of confinement environments using this?

>
> > Since uretprobe is a "kernel implementation detail" system call which is
> > not used by userspace application code directly, pass this system call
> > through seccomp without forcing existing userspace confinement environments
> > to be changed.
>
> This makes me feel kinda uncomfortable. The purpose of seccomp() is
> that you can create a process that is as locked down as you want; you
> can use it for some light limits on what a process can do (like in
> Docker), or you can use it to make a process that has access to
> essentially nothing except read(), write() and exit_group(). Even
> stuff like restart_syscall() and rt_sigreturn() is not currently
> excepted from that.

Yes, this has been discussed at length in the threads mentioned
in the "Link" tags.

>
> I guess your usecase is a little special in that you were already
> calling from userspace into the kernel with SWBP before, which is also
> not subject to seccomp; and the syscall is essentially an
> arch-specific hack to make the SWBP a little faster.

Indeed. The uretprobe mechanism wasn't enforced by seccomp before
this syscall. This change preserves this.

>
> If we do this, we should at least ensure that there is absolutely no
> way for anything to happen in sys_uretprobe when no uretprobes are
> configured for the process - the first check in the syscall
> implementation almost does that, but the implementation could be a bit
> stricter. It checks for "regs->ip != trampoline_check_ip()", but if no
> uprobe region exists for the process, trampoline_check_ip() returns
> `-1 + (uretprobe_syscall_check - uretprobe_trampoline_entry)`. So
> there is a userspace instruction pointer near the bottom of the
> address space that is allowed to call into the syscall if uretprobes
> are not set up. Though the mmap minimum address restrictions will
> typically prevent creating mappings there, and
> uprobe_handle_trampoline() will SIGILL us if we get that far without a
> valid uretprobe.

I'm not sure I understand your point. If creating mappings in that
area is prevented, what is the issue? also, this would be related to the
uretprobe syscall implementation in general, no?

To me this seems unrelated to the seccomp change.
Jiri, do you have any input on this?

Thanks!
Eyal.