I also want to stress that when we think about LSM controls, we need to think in generic terms and not solely on a specific LSM, e.g. BPF. It's fine and good to have documentation about how one might use a BPF LSM to mitigate access to a coredump socket, but it should be made clear in that same documentation that other LSMs may also be enforcing access controls on that socket. Further, and I believe everyone here already knows this, but just to be clear, the kernel code should definitely not assume either the presence of a specific LSM, or the LSM in general. > > > I just found it more elegant to simply guarantee that only connections > > > are made to that socket come from coredumping tasks. > > > > > > But I should note there are two ways to cleanly handle this in > > > userspace. I had already mentioned the bpf LSM in the contect of > > > rate-limiting in an earlier posting: > > > > > > (1) complex: > > > > > > Use a bpf LSM to intercept the connection request via > > > security_unix_stream_connect() in unix_stream_connect(). > > > > > > The bpf program can simply check: > > > > > > current->signal->core_state > > > > > > and reject any connection if it isn't set to NULL. > > > > > > The big downside is that bpf (and security) need to be enabled. > > > Neither is guaranteed and there's quite a few users out there that > > > don't enable bpf. > > The kernel should indeed always have a minimal security policy in place, > LSM can tailored that but we should not assume that a specific LSM with > a specific policy is enabled/configured on the system. None of the LSM mailing lists were CC'd so I haven't seen the full thread yet, and haven't had the chance to dig it up on lore, but at the very least I would think there should be some basic controls around who can bind/receive coredumps. -- paul-moore.com
