Open dkess opened 1 month ago
How did you test the change? Just opening an existing tomb? Or also creating a new one?
If I test lock
ing a new tomb with a key, then it will fail at one location for me:
./tomb lock --sudo run0 run0.tomb -k run0.key
tomb . Privilege escalation tool configured: run0
tomb . File is not yet a tomb: run0.tomb
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as:
Password:
==== AUTHENTICATION COMPLETE ====
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as:
Password:
==== AUTHENTICATION COMPLETE ====
tomb . Valid tomb file found: run0.tomb
tomb . Commanded to lock tomb run0.tomb
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as:
Password:
==== AUTHENTICATION COMPLETE ====
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as:
Password:
==== AUTHENTICATION COMPLETE ====
tomb . Checking if the tomb is empty (we never step on somebody else's bones).
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as:
Password:
==== AUTHENTICATION COMPLETE ====
tomb . Fine, this tomb seems empty.
tomb . Key is valid.
tomb . Locking using cipher: aes-xts-plain64
tomb . A password is required to use key run0.key
tomb . Password OK.
tomb (*) Locking run0.tomb with run0.key
tomb . Formatting Luks mapped device.
Failed to start transient service unit: Interactive authentication required.
tomb [W] cryptsetup luksFormat returned an error.
tomb [E] Operation aborted.
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as:
Password:
==== AUTHENTICATION COMPLETE ====
But didn't look yet, what could be the cause that the luksFormat
operation is failing.
Oh yeah I didn't test creating a new tomb. I'm not sure what would cause that error.
Is there a github action os that has run0 ? I think this is too early as its a moving target and wouldn't be checked test units yet.
Ubuntu 24.04 and Fedora-latest should still be on 255. run0 was added with 256.
But indirectly it could eventually be used as there is also the container
option for docker container.
Example of such a workflow: https://github.com/labwc/labwc/blob/master/.github/workflows/build.yml
But dunno if run0 will work in a container. I have a fairly simple nspawn container and therein it doesn't work. But could also be a configuration issue and docker is using different tech.
ACK, complex enough with no need to. Let's check back later when its mainstream. I would also add a warning about systemd being generally insecure, having generated a lot of additional CVEs to distros until now and most likely in the future. Thanks for debunking this
run0 is a new sudo replacement built into systemd, see https://www.freedesktop.org/software/systemd/man/devel/run0.html.
I tested this with tomb and it looks like it works without any additional changes, so it should be fine to just add it to the allowlist.