From: domg472@gmail.com (Dominick Grift) Date: Thu, 13 Jan 2011 13:34:22 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <1294921531.3112.18.camel@tesla.lan> References: <1294867930.1731.34.camel@tesla.lan> <4D2EC398.7060304@gmail.com> <1294921531.3112.18.camel@tesla.lan> Message-ID: <4D2EF14E.8020903@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 01:25 PM, Guido Trentalancia wrote: > 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... I sincerely doubt that, but then again i may be wrong. Can you reproduce this? > 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 ? There should not be anything mysterious about SELinux. I will not speculate as to your specific issue. I would need to see the AVC denials to be able to make a decent suggestion. I will however say that you also have to be aware of any constraints that may influence access decisions (not only type enforcement) > Best regards, > > Guido Trentalancia > > On Thu, 13/01/2011 at 10.19 +0100, Dominick Grift wrote: > 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 > _______________________________________________ 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/ iEYEARECAAYFAk0u8U4ACgkQMlxVo39jgT9ovgCgiX9NIppCPWEjvCYni5/yTn9I O30An1jLL1RF0Dv/dmC0Bdvh1ucb2zr5 =aIak -----END PGP SIGNATURE-----