linux-kernel - Re: [PATCH] seccomp: passthrough uretprobe systemcall without filtering

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: <Z4-xeFH0Mgo3llga@krava>
Date: Tue, 21 Jan 2025 15:38:48 +0100
From: Jiri Olsa <olsajiri@...il.com>
To: Eyal Birger <eyal.birger@...il.com>
Cc: Kees Cook <kees@...nel.org>, luto@...capital.net, wad@...omium.org,
	oleg@...hat.com, ldv@...ace.io, 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,
	stable@...r.kernel.org
Subject: Re: [PATCH] seccomp: passthrough uretprobe systemcall without
 filtering

On Sat, Jan 18, 2025 at 07:39:25PM -0800, Eyal Birger wrote:

SNIP

> I think I wasn't accurate in my wording.
> The uretprobe syscall is added to the tracee by the kernel.
> The tracer itself is merely requesting to attach a uretprobe bpf
> function. In previous versions, this was implemented by the kernel
> installing an int3 instruction, and in the new implementation the kernel
> is installing a uretprobe syscall.
> The "user" in this case - the tracer program - didn't deliberately install
> the syscall, but anyway this is semantics.
> 
> I think I understand your point that it is regarded as "policy", only that
> it creates a problem in actual deployments, where in order to be able to
> run the tracer software which has been working on newer kernels a new docker
> has to be deployed.
> 
> I'm trying to find a pragmatic solution to this problem, and I understand
> the motivation to avoid policy in seccomp.
> 
> Alternatively, maybe this syscall implementation should be reverted?

you mentioned in the previous reply:

> > As far as I can tell libseccomp needs to provide support for this new
> >  syscall and a new docker version would need to be deployed, so It's not
> > just a configuration change. Also the default policy which comes packed in
> > docker would probably need to be changed to avoid having to explicitly
> > provide a seccomp configuration for each deployment.

please disregard if this is too stupid.. but could another way out be just
to disable it (easy to do) and meanwhile teach libseccomp to allow uretprobe
(or whatever mechanism needs to be added to libseccomp) plus the needed
docker change ... to minimize the impact ? 

or there's just too many other seccomp user space libraries

I'm still trying to come up with some other solution but wanted
to exhaust all the options I could think of

thanks,
jirka