From: Kuniyuki Iwashima <kuniyu@xxxxxxxxxx> Date: Mon, 5 May 2025 12:35:50 -0700 > 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 and LSM can check if the source socket is a kernel socket too. > > 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. > >
