Now that I have had more time to ponder this issue, I realize that it is also a security vulnerability. And spurred by the realization, I vaguely recall coming across several articles in the past (some from before systemd was a thing) about how automatic runtime cleaning of /tmp and /var/tmp is (or can be) a security issue.
Firstly, an attacker (an unprivileged local user in this context) may be able to control what files are removed in the cleanup, though it may be possible to mitigate/prevent this by properly hardening the cleanup program. More importantly, when files or directories of long-running processes (that assume they still have full control over them) are removed in the cleanup, the attacker can hijack them by recreating them, thus possibly gaining read/write capabilities beyond their privileges. For example, replacing a file still used by a process (though obviously not for a while since it got cleaned) with a symlink, it may be possible to overwrite arbitrary system files. As a more specific example applicable to a current Ubuntu 24.04.1 setup, if an X server is not started for a month after system boot, /tmp/.X11-unix gets removed. The attacker can then create it, and as owner will be able to rename files it contains. So when an X server is later started, rename the socket X0 to X0-foo, create your own socket X0 and you will have MitM eavesdropping/tampering on another user's X display. ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2088268 Title: systemd /tmp cleaning removes files that it shouldn't Status in systemd package in Ubuntu: New Bug description: On Ubuntu 24.04.1, systemd 255.4-1ubuntu8.4, the fix for bug #2019026 causes files under /tmp to be removed if their age is greater than 30 days. However, there are files under /tmp that should not be removed at runtime regardless of their age (whether they belong in that directory at all is a separate question), for example those listed in /usr/lib/tmpfiles.d/x11.conf (I have witnessed the disappearance of X11 lock files, though the sockets are still there; /tmp/.XIM-unix and /tmp/.font-unix have also disappeared). I am not familiar enough with systemd-tmpfiles to figure out whether those files can be properly protected from removal with a tmpfiles.d configuration change, but I do know that the current configuration does not do that. I noticed this problem when a couple of TigerVNC sessions became inaccessible a month after starting them, which turned out to be because the "cached" password file in /tmp/tigervnc.XXXXXX/passwd was removed. This is at least partially a bug in tigervnc, but the problem also affects other critical not-to-be-removed-or-else files under /tmp. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2088268/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
