Re: Another getcon() vs getcon_raw() issue in systemd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 30, 2016 8:08 AM, "Russell Coker" <russell@xxxxxxxxxxxx> wrote:
On Monday, 26 December 2016 7:10:19 PM AEDT Nicolas Iooss wrote:
> With the output you gave I searched in D-Bus source how the
> LinuxSecurityLabel was computed here. I discovered a lot of files in dbus/
> directory which seem to duplicate things from bus/ I have described in my
> previous email. In dbus/dbus-sysdeps-unix.c there is a function which calls
> "getsockopt (client_fd, SOL_SOCKET, SO_PEERSEC, ...)" in order to get this
> "system_u:system_r:systemd_machined_t:s0"
> (add_linux_security_label_to_credentials,
> https://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c?h=dbus-> 1.10#n1760). This function queries the same kernel API as libselinux's
> getpeercon_raw(), but without using libselinux (which is normal as it can
> also returns Smack or AppArmor labels). This is why the context is not
> translated.
>
> The documentation of GetConnectionCredentials->LinuxSecurityLabel is way
> better than the one of GetConnectionSELinuxSecurityContext in D-Bus
> specification (
> https://cgit.freedesktop.org/dbus/dbus/tree/doc/dbus-specification.xml?h=dbu
> s-1.10#n6030) so if I were to decide, I would rather migrate systemd's
> bus_get_name_creds_dbus1() to GetConnectionCredentials (in
> https://github.com/systemd/systemd/blob/v232/src/libsystemd/sd-bus/bus-contr
> ol.c#L865). However this implies some non-trivial systemd code modifications
> and I do not know how systemd developers are willing to modify this part of
> their code.
> An other option consists in making D-Bus use getpeercon_raw() in
> GetConnectionSELinuxSecurityContext (and documenting this in the D-Bus
> spec). I do not know what subtle side-effects such a change would have on a
> system (a quick search of users of this interface on searchcode.com gave
> some Android-related projects).

Thanks for your suggestions.  I ran a VM of Fedora 24 with my policy to test
this.  Fedora 24 ran well with that and gave no such errors.  Fedora has dbus
1.11.8 (development) and systemd 229 while Debian/Unstable has dbus 1.10.14
(stable) and systemd 332.

A did a diff on the Fedora 24 dbus source and the Debian dbus source and
didn't find anything that seemed to be related.  So I presume that it's more
related to systemd - which doesn't necessarily imply that changing systemd is
the correct way to fix it.

I'll try rawhide now.

Fedora no longer runs mcstransd by default, so that may also be relevant.  Dbusd should likely provide the raw context to clients so that they are free to use either the raw or translated interfaces without difficulty. 


--
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.

_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux