On 9/24/25 00:38, Lennart Poettering wrote: > 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.
Could this be combined with ensuring that the global mount is *not* in the mount namespace of the confined service? If so, I think this addresses the concern, provided that there is a separate SELinux contexts for credentials *and* preventing use of file descriptors passed via SCM_RIGHTS is not a concern. > 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. SELinux really shines in embedded systems, Android, and Chromium OS, where one can make a closed-world assumption. Sandboxing a generic service is much more difficult. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
