The dbus-daemon has a GetConnectionSELinuxSecurityContext() method. There are two problems with this method: * in Bug #54445 I added a GetConnectionCredentials() call which is meant to return all available credentials, but I don't use SELinux, so I didn't want to add functionality I can't test; * the documentation in the D-Bus Specification is extremely vague because I don't know what the right jargon is, or what a sensible example looks like I would be happy to review a patch that corrected either or both of these. There is some synergy with Bug #75113 asking for AppArmor support, which also wants to add support for a not-necessarily-UTF-8 credential. In particular, Attachment #97993 [details] (or whatever supersedes it if Tyler changes it) seems like it is likely to be useful here. https://bugs.freedesktop.org/show_bug.cgi?id=75113#c75 explains why, even though GetConnectionSELinuxSecurityContext returns ['f', 'o', 'o'] if the context is "foo", it would be nicer for the SELinux security context in GetConnectionCredentials to be ['f', 'o', 'o', '\0'].
(In reply to Simon McVittie from comment #0) > * in Bug #54445 I added a GetConnectionCredentials() call which is meant > to return all available credentials, but I don't use SELinux, so I didn't > want to add functionality I can't test An update on this: now that the LSM label in GetConnectionCredentials() is LSM-agnostic, and essentially defined to be "whatever the kernel tells us via getsockopt SO_PEERSEC", we do report SELinux labels there. Anecdotal evidence from https://www.spinics.net/lists/selinux/msg21149.html is that it might look like system_u:system_r:systemd_machined_t:s0 and in particular is the same string that getpeercon_raw() returns. > * the documentation in the D-Bus Specification is extremely vague > because I don't know what the right jargon is, or what a sensible example > looks like This is still a problem. People who understand SELinux are invited to tell us what it is that GetConnectionSELinuxSecurityContext() actually does. (There is a suggestion in that mail that GetConnectionSELinuxSecurityContext() is not necessarily actually very useful, because it always calls getpeercon() but SELinux users would sometimes prefer getpeercon_raw(), similar to the distinction between AppArmor contexts and AppArmor label/confinement pairs. That would be another reason to document it as deprecated in favour of GetConnectionCredentials().) > even > though GetConnectionSELinuxSecurityContext returns ['f', 'o', 'o'] if the > context is "foo", it would be nicer for the SELinux security context in > GetConnectionCredentials to be ['f', 'o', 'o', '\0']. The security context in GetConnectionCredentials() always gets a trailing \0, as desired.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/112.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.