Potential systemd CoredumpFilter sandboxing issue

[daechir]

Hello again,
Thanks for fixing the utmp build issue from Nov 2023. I lost the email and couldn't figure out how to write to it.

I found another issue that seems to be a bit more complicated. I'll try to describe it as best I can.

When booting with the kernel parameter coredump_filter=0x0, all processes should read coredump_filter (at /proc/*/coredump_filter) as 00000000, or private-anonymous. This behavior works as intended. However, when specifying this kernel parameter, and also setting the systemd sandboxing option CoredumpFilter=private-anonymous, some services still tend to ignore or overwrite this value. I have found with v255 that /usr/lib/systemd/systemd --user is one such example, or user at .service which sets its /proc/*/coredump_filter to 00000001 instead.

Am I wrong in understanding that private-anonymous usually maps to 00000000?
Also, wouldn't 00000001 show something like coredump_filter=0x01 or CoredumpFilter=shared-anonymous?

Here is some version info if you need it:
linux-hardened v6.6.8
systemd v255.r70031.307b6a4dab-1

In case this is related to a conflicting sandboxing option, here is the full user at .service file for review.
https://gitlab.com/xenos-install-kit/xenos-install-kit/-/blob/main/S2/usr/lib/systemd/system/user@.service?ref_type=heads

Let me know if you need anything else from me.

Best,
Daechir


Sent with Proton Mail secure email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240108/b4b15cb5/attachment.sig>