On Di, 23.09.25 18:26, Demi Marie Obenour ([email protected]) wrote: > On 9/23/25 17:56, Luca Boccassi wrote: > > On Tue, 23 Sept 2025 at 22:45, Ian Pilcher <[email protected]> wrote: > >> This was discussed in this issue[1], but the issue was closed without > >> any real resolution. (Giving a confined service access to everything > >> labeled var_run_t is most definitely not acceptable.) > > > > Sorry, but this is a self-imposed restriction that doesn't need to be > > in place. You can absolutely change the policy to allow that access. > > If you want to sandbox a service, you can use the appropriate > > sandboxing properties, like TemporaryFilesystem=/run/ and then only > > BindPaths= the individual things you want it to access. > > > > If you don't want to change the policy to allow a service to access > > creds then yeah there's not much to do, but there's no reason not to. > > One class of vulnerabilities SELinux protects from is path traversal > bugs in privileged services. Those can allow the service to access > any *path* on the filesystem, but SELinux doesn't care about paths. > It cares about inode labels, and those will block the access. > > Does systemd guarantee that the credentials are not exposed > *via any path on the filesystem* to anything but the service > that should have access to them?
I am pretty sure a better approach to attack such vulnerabilities is locking services into mount namespaces that create a separate "world" the services live in, without general visibility of the host's resources. In systemd, credential use does *not* imply mount namespacing (simply because there are service we cannot really use mount namespacing for, but for which we would really like to use credentials, for example systemd-tmpfiles, which is supposed to make changes to the host /run/ or /etc/ after all), but credentials are expressly *designed* to be used in a mount namespaced context: if they are combined with any of the mount namespacing knobs, then the mount where the plaintext creds are placed in for the service only exists in that service's mount namespace, not outside. I think making inodes invisible to anyone but the service that shall have them via mount namespacing is a much better approach than trying to put selinux labels on everything and hoping the selinux policy is carefully written enough to understand which inode is which and prohibit access. While it is certainly possibly to fuck up the namespacing thing (simply by not turning it on for a service), I do believe it is much harder to fuck it up then fucking up the selinux policy that would do something even roughly equivalent, if you follow what I am trying to say. Lennart -- Lennart Poettering, Berlin
