On Wed, May 7, 2025 at 7:54 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > On Tue, May 06, 2025 at 12:18:12PM -0700, Kuniyuki Iwashima wrote: > > From: Christian Brauner <brauner@xxxxxxxxxx> > > Date: Tue, 6 May 2025 10:06:27 +0200 > > > On Mon, May 05, 2025 at 09:10:28PM +0200, Jann Horn wrote: > > > > 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. > > > > > > > > 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. > > > > > > > > > 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. > > > > > > I think Kuniyuki's point is defensible. And I did discuss this with > > > Lennart when I wrote the patch and he didn't see a point in preventing > > > other processes from connecting to the core dump socket. He actually > > > would like this to be possible because there's some userspace programs > > > out there that generate their own coredumps (Python?) and he wanted them > > > to use the general coredump socket to send them to.
