[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250506-buchmacher-gratulant-9960af036671@brauner>
Date: Tue, 6 May 2025 17:16:13 +0200
From: Christian Brauner <brauner@...nel.org>
To: Jann Horn <jannh@...gle.com>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, alexander@...alicyn.com,
bluca@...ian.org, daan.j.demeyer@...il.com, davem@...emloft.net,
david@...dahead.eu, edumazet@...gle.com, horms@...nel.org, jack@...e.cz,
kuba@...nel.org, lennart@...ttering.net, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, me@...dnzj.com, netdev@...r.kernel.org, oleg@...hat.com,
pabeni@...hat.com, viro@...iv.linux.org.uk, zbyszek@...waw.pl
Subject: Re: [PATCH RFC v3 08/10] net, pidfs, coredump: only allow
coredumping tasks to connect to coredump socket
On Tue, May 06, 2025 at 04:51:25PM +0200, Jann Horn wrote:
> On Tue, May 6, 2025 at 9:39 AM Christian Brauner <brauner@...nel.org> wrote:
> > > ("a kernel socket" is not necessarily the same as "a kernel socket
> > > intended for core dumping")
> >
> > Indeed. The usermodehelper is a kernel protocol. Here it's the task with
> > its own credentials that's connecting to a userspace socket. Which makes
> > this very elegant because it's just userspace IPC. No one is running
> > around with kernel credentials anywhere.
>
> To be clear: I think your current patch is using special kernel
> privileges in one regard, because kernel_connect() bypasses the
> security_socket_connect() security hook. I think it is a good thing
> that it bypasses security hooks in this way; I think we wouldn't want
> LSMs to get in the way of this special connect(), since the task in
> whose context the connect() call happens is not in control of this
> connection; the system administrator is the one who decided that this
> connect() should happen on core dumps. It is kind of inconsistent
> though that that separate security_unix_stream_connect() LSM hook will
> still be invoked in this case, and we might have to watch out to make
> sure that LSMs won't end up blocking such connections... which I think
Right, it is the same as for the usermode helper. It calls
kernel_execve() which invokes at least security_bprm_creds_for_exec()
and security_bprm_check(). Both of which can be used to make the
usermodehelper execve fail.
Fwiw, it's even the case for dumping directly to a file as in that case
it's subject to all kinds of lookup and open security hooks like
security_file_open() and then another round in do_truncate().
All of that happens fully in the task's context as well via
file_open()/file_open_root() or do_truncate().
So there's nothing special here.
Powered by blists - more mailing lists