From: Jann Horn <jannh@xxxxxxxxxx> Date: Mon, 5 May 2025 21:10:28 +0200 > On Mon, May 5, 2025 at 8:41 PM Kuniyuki Iwashima <kuniyu@xxxxxxxxxx> wrote: > > From: Christian Brauner <brauner@xxxxxxxxxx> > > Date: Mon, 5 May 2025 16:06:40 +0200 > > > On Mon, May 05, 2025 at 03:08:07PM +0200, Jann Horn wrote: > > > > On Mon, May 5, 2025 at 1:14 PM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > > Make sure that only tasks that actually coredumped may connect to the > > > > > coredump socket. This restriction may be loosened later in case > > > > > userspace processes would like to use it to generate their own > > > > > coredumps. Though it'd be wiser if userspace just exposed a separate > > > > > socket for that. > > > > > > > > This implementation kinda feels a bit fragile to me... I wonder if we > > > > could instead have a flag inside the af_unix client socket that says > > > > "this is a special client socket for coredumping". > > > > > > Should be easily doable with a sock_flag(). > > > > This restriction should be applied by BPF LSM. > > I think we shouldn't allow random userspace processes to connect to > the core dump handling service and provide bogus inputs; that > unnecessarily increases the risk that a crafted coredump can be used > to exploit a bug in the service. So I think it makes sense to enforce > this restriction in the kernel. It's already restricted by /proc/sys/kernel/core_pattern. We don't need a duplicated logic. Even when the process holding the listener dies, you can still avoid such a leak. e.g. 1. Set up a listener 2. Put the socket into a bpf map 3. Attach LSM at connect() Then, the LSM checks if the destination socket is * listening on the name specified in /proc/sys/kernel/core_pattern * exists in the associated BPF map So, if the socket is dies and a malicious user tries to hijack the core_pattern name, LSM still rejects such connect(). Later, the admin can restart the program with different core_pattern. > > My understanding is that BPF LSM creates fairly tight coupling between > userspace and the kernel implementation, and it is kind of unwieldy > for userspace. (I imagine the "man 5 core" manpage would get a bit > longer and describe more kernel implementation detail if you tried to > show how to write a BPF LSM that is capable of detecting unix domain > socket connections to a specific address that are not initiated by > core dumping.) I would like to keep it possible to implement core > userspace functionality in a best-practice way without needing eBPF. I think the untrusted user scenario is paranoia in most cases, and the man page just says "if you really care, use BPF LSM". If someone can listen on a name AND set it to core_pattern, most likely something worse already happened. > > > It's hard to loosen such a default restriction as someone might > > argue that's unexpected and regression. > > If userspace wants to allow other processes to connect to the core > dumping service, that's easy to implement - userspace can listen on a > separate address that is not subject to these restrictions. >
