Open pabs3 opened 3 years ago
poettering
commented
3 years ago umpf. we only expose external metadata in the coredump, basically information roughly similar to what other users see in "ps" too, i.e. stuff you can mostly see from /proc/ while the process is running. I am not convinced we need stricter controls here.
Or to say this differently: unless kernels/distros switch to a /proc that hides everyones data i don't really see the point of this request I must say.
pabs3
commented
3 years ago I see now that the Linux proc.privacy patches from 2005 never actually got merged. OTOH, there is now the hidepid procfs mount option, which does something similar, can be enabled by sysadmins and is even used by systemd for the ProtectProc option. There are also pid namespaces that hide processes from other processes. The procfs now supports multiple /proc instances even inside the same pid namespace. So there are multiple ways of hiding info about processes that may get bypassed when those processes crash and systemd-coredump saves core dump metadata.
-- bye, pabs
poettering
commented
3 years ago So system-wide hidepid= doesn't work on general purpose distros, you have stuff such as polkit that needs to be able to look into /proc.
per-service hidepid= (i.e. ProtectProc=) makes a lot of sense, but it's implemented via mount namespacing. But if you do mount namespacing I'd really hide the whole dir coredump anyway.
pabs3
commented
3 years ago AFAICT, polkit runs as root and with hidepid=2, root can still see all processes so polkit should not be affected by hidepid. Agreed there are probably other non-root processes that break with hidepid and I haven't seen any bugs about those but I see from #12955 and #16825 that the systemd service manager is affected.
-- bye, pabs
danielzgtg
commented
2 years ago basically information roughly similar to what other users see in "ps" too, i.e. stuff you can mostly see from /proc/ while the process is running. I am not convinced we need stricter controls here.
This ignores forward secrecy regardless of and separate from procfs' hidepid. If a program crashes at one moment in the past leaving a crashdump, another user 1 second in the future should not be able to see the program name in the present. Even if they are authorized to see the program names in general, they might have not been authorized to log in at the previous time.
Therefore to fix forward secrecy, we need to implement this. How about ~/.local/lib/systemd/coredump or $XDG_RUNTIME_DIR/lib/systemd/coredump?
Is your feature request related to a problem? Please describe.
I recently switched from a different core dump handler to systemd-coredump and I noticed that it leaks information about core dumps across user boundaries. The core dumps are all stored in one directory
/var/lib/systemd/coredumpso any user can read the metadata stored in the core dump filenames. Thecoredumpctlcommand also lists and prints info for core dumps from any user. The core dump itself is of course inaccessible, but some of the metadata could be private information and the fact that a particular application crashed could be useful information when trying to break into another user account.Describe the solution you'd like
/var/lib/systemd/coredump, so that the existence of the per-uid directory doesn't leak information about whether a crash has happened or not./var/lib/systemd/coredumpso that the size/blocks of each per-uid subdirectory cannot leak information about whether a crash has happened or not.coredumpctlsuch that each user only has access to metadata for their own core dumps.Describe alternatives you've considered
Avoid using systemd-coredump on multi-user systems where crash metadata leakage could be problematic.
The systemd version you checked that didn't have the feature you are asking for 249.4