From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 13 Jan 2011 13:25:31 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <4D2EC398.7060304@gmail.com> References: <1294867930.1731.34.camel@tesla.lan> <4D2EC398.7060304@gmail.com> Message-ID: <1294921531.3112.18.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Dominick and thanks very much for your message ! The problem appears to be mostly sorted out now. The point is that I am not able to reproduce it again. As far as I remember, there were only a wrong PAM file for gdm and an old dbus-daemon-launch-helper in /usr/libexec. But then reverting back those changes doesn't reproduce the problem. In any case at the moment nothing except init runs in any init* context. But there is still something interesting to speculate. The main effect of the problem as I had originally reported was that it was not possible to login into gdm which I use as the graphical login manager. What is worrying is that when the init binary was not labelled correctly and thus init/upstart was running in a wrong context (something like system_u:system_r:insmod_t as far as I can remember) it was possible to login into gdm. If you remember I mentioned in my original message about the fact that refpolicy unfortunately does not yet label /sbin/upstart correctly because it's missing from the default file_contexts... This is quite worrying. So, despite init was running in a wrong context (and despite the wrong gdm PAM file), it was still possible to login into gdm while it wasn't possible when init was running in the proper context... However, in the current situation I am still getting some USER_AVC "denied" send_msg about dbus messages (in the audit log only). At a very quick first check, at least some of those messages should have been allowed according to /etc/dbus-1/system.d/* policies. I now need to look at that in more detail. In general what should be done if those messages are allowed by dbus policies but then are (mysteriously) denied by SELinux ? Best regards, Guido Trentalancia On Thu, 13/01/2011 at 10.19 +0100, Dominick Grift wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/12/2011 10:32 PM, Guido Trentalancia wrote: > > Hello, > > > > I have just built and installed refpolicy-2.20101213 (mcs) but I get > > problems with dbus, such as the following: > > > > Jan 11 18:54:04 tesla gnome-session[2744]: WARNING: Could not connect to > > ConsoleKit: An SELinux policy prevents this sender from sending this > > message to this recipient (rejected message had sender "(unset)" > > interface "org.freedesktop.DBus" member "Hello" error name "(unset)" > > destination "org.freedesktop.DBus") > > Jan 11 07:41:59 tesla gdm-binary[2513]: WARNING: Couldn't connect to > > system bus: An SELinux policy prevents this sender from sending this > > message to this recipient (rejected message had sender "(unset)" > > interface "org.freedesktop.DBus" member "Hello" error name "(unset)" > > destination "org.freedesktop.DBus") > > Jan 12 21:58:29 tesla pulseaudio[31181]: hal-util.c: Unable to contact > > DBUS system bus: org.freedesktop.DBus.Error.AccessDenied: An SELinux > > policy prevents this sender from sending this message to this recipient > > (rejected message had sender "(unset)" interface "org.freedesktop.DBus" > > member "Hello" error name "(unset)" destination "org.freedesktop.DBus") > > > > or in terms of audit, things like: > > > > type=USER_AVC msg=audit(1294728121.875:414): user pid=6167 uid=81 > > auid=4294967295 ses=4294967295 > > subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied > > { send_msg } for msgtype=method_call interface=org.freedesktop.DBus > > member=Hello dest=org.freedesktop.DBus spid=6211 > > scontext=system_u:system_r:initrc_t:s0 > > tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus : > > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' > > type=USER_AVC msg=audit(1294728121.925:415): user pid=6167 uid=81 > > auid=4294967295 ses=4294967295 > > subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='avc: denied > > { send_msg } for msgtype=method_call interface=org.freedesktop.DBus > > member=Hello dest=org.freedesktop.DBus spid=6222 > > scontext=system_u:system_r:initrc_t:s0 > > tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=dbus : > > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' > > > > Now, the dbus module is loaded: > > > > dbus 1.14.0 > > > > I had to relabel /sbin/upstart by modifying the default contexts. In > > fact, nowadays /sbin/init is often a symlink to /sbin/upstart (see > > Debian, Fedora and possibly others) but unfortunately this is not > > contemplated in the default file_contexts. > > > > Anyway, after relabelling /sbin/upstart sestatus also looks fine: > > > > SELinux status: enabled > > SELinuxfs mount: /selinux > > Current mode: enforcing > > Mode from config file: permissive > > Policy version: 24 > > Policy from config file: refpolicy-mcs > > > > Process contexts: > > Current context: > > system_u:system_r:local_login_t:s0-s0:c0.c1023 > > Init context: system_u:system_r:init_t:s0 > > /sbin/mingetty system_u:system_r:getty_t:s0 > > > > So, what is missing ? Any idea on how to sort this out would be greatly > > appreciated ! > > Something runs in initrc_t where it probably should not. Could well be > the dbus system bus. I do not know. ps auxZ | grep initrc_t would > probably reveal it. > > Once its determined which process runs initrc_t, you can target your > troubleshoot efforts to this process. > > > > Regards, > > > > Guido > > > > _______________________________________________ > > refpolicy mailing list > > refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk0uw5gACgkQMlxVo39jgT/xiQCgxKBe3e2bqSYo6QvDTH3HgQJs > iB8AnAkGefZcGAI1ULL5XgkeEGOLWhlQ > =MJL+ > -----END PGP SIGNATURE----- > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy >