Bug 84193

Summary:	someone who understands SELinux should improve its documentation
Product:	dbus	Reporter:	Simon McVittie <smcv>
Component:	core	Assignee:	D-Bus Maintainers <dbus>
Status:	RESOLVED MOVED	QA Contact:	D-Bus Maintainers <dbus>
Severity:	enhancement
Priority:	low	CC:	bigon, msniko14, russell, walters
Version:	1.5	Keywords:	love
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Simon McVittie 2014-09-22 15:51:44 UTC

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'].

Comment 1 Simon McVittie 2016-12-30 21:30:16 UTC

(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.

Comment 2 GitLab Migration User 2018-10-12 21:21:21 UTC

-- 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.