On Fri, 30 Dec 2016 at 23:55:58 +1100, Russell Coker wrote: > Below is part of the SE Linux audit log on one of my test systems. These > entries have a MCS context of "s0" which is being translated to "SystemLow" > in a very similar way to translating a UID to a username. However the > software > which processes the audit log expects to have a non-translated MCS context so > this causes problems.
What component emits those log messages? It looks as though it's pid 1, the system instance of systemd? > https://www.spinics.net/lists/selinux/msg21149.html > > This URL has the archive of a mailing list discussion about this topic. It > seems that changes to systemd or dbus could be used to resolve this. The D-Bus documentation that says Returns the security context used by SELinux, in an unspecified format. If you know what this means, please contribute documentation via the D-Bus bug tracking system. is because before I added that sentence, GetConnectionSELinuxSecurityContext() was not documented at all. However, I didn't (and still don't) know the specifics of that method, so I documented its existence and left it to others to fill in the blanks. That was almost four years ago. If you know enough about SELinux to give a more precise description or can quote some likely examples of what a user of SELinux would get by calling that method (similar to the ones given for AppArmor), please send a patch upstream so we can document it better. The point of contact for upstream bug reports and code contributions is <https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core> and the specification is doc/dbus-specification.xml in the dbus source tree. https://bugs.freedesktop.org/show_bug.cgi?id=84193 is a relevant upstream bug that I opened when I added the initial documentation. In particular, the distinction between translated and non-translated MCS contexts (and which one gets reported) should be mentioned there - but until today I didn't know that a translated MCS context was a phrase that makes sense, so I am really not the right person to be writing that documentation! dbus' AppArmor support was added much later than its SELinux support, so it has been through a lot more review, has more documentation, and we have a better picture of what is appropriate. If you can bring SELinux up to the same standard, that would be much appreciated. Given that GetConnectionSELinuxSecurityContext() seems to have returned the same thing for about 10 years, I think making the documentation describe existing behaviour would be a lot more appropriate than changing its behaviour and only documenting the new version. > It seems GetConnectionCredentials should be preferred. Yes. GetConnectionCredentials() returns the uid, the pid, and the raw form of any applicable LSM label in a single round-trip, making it more efficient than the older single-credential methods like GetConnectionUnixUserID() and GetConnectionSELinuxSecurityContext(). If D-Bus is used as intended then it is not normally a performance bottleneck; but if its performance does become relevant, then it's usually number of message round-trips per second, rather than number of bytes per second, that is the limiting factor. If GetConnectionCredentials() also returns the information you actually want, where GetConnectionSELinuxSecurityContext() doesn't, then that's an additional reason to prefer it. > I don't know a lot about dbus. We don't know a lot about SELinux. Unfortunately, the SELinux code in dbus was mostly committed a decade ago, prior to my involvement in dbus and before we had a systematic "audit trail" of upstream bug reports, so there's nothing else I can look up to find out why. If it's systemd that's emitting these messages, and it can make them better/more appropriate by calling GetConnectionCredentials() rather than GetConnectionSELinuxSecurityContext(), then I think it's systemd that should change to call GetConnectionCredentials(). > An other option consists in making D-Bus use getpeercon_raw() in > GetConnectionSELinuxSecurityContext (and documenting this in the > D-Bus spec). I think it would be a bad idea to change the (undocumented!) semantics of this method - that seems quite likely to break other projects' assumptions, and it has had its current behaviour for more than 10 years. I am definitely not going to change the meaning of that method as a Debian-specific patch, and I don't think it would be appropriate to change it on the upstream 1.10.x stable-branch either. However, if you want to pursue this route, the way to do so would be to talk to the D-Bus upstream maintainers via <https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core>. I don't use or understand SELinux, but some of the other upstream maintainers might. S
