From: domg472@gmail.com (Dominick Grift) Date: Thu, 13 Jan 2011 16:38:35 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <1294931759.3153.25.camel@tesla.lan> References: <1294867930.1731.34.camel@tesla.lan> <4D2EC398.7060304@gmail.com> <1294921531.3112.18.camel@tesla.lan> <4D2EF14E.8020903@gmail.com> <1294931759.3153.25.camel@tesla.lan> Message-ID: <4D2F1C7B.5040206@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 04:15 PM, Guido Trentalancia wrote: > Hello again Dominick ! > > On Thu, 13/01/2011 at 13.34 +0100, Dominick Grift wrote: >> -----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? > > Yes confirmed and it can be easily reproduced. > > When /sbin/upstart is mislabelled as system_u:object_r:bin_t:s0 as it > would happen with an unmodified refpolicy-2.20101213, sestatus reports: > > Process contexts: > Current context: system_u:system_r:kernel_t:s0 > Init context: system_u:system_r:kernel_t:s0 > /sbin/mingetty system_u:system_r:kernel_t:s0 > > But the system appears to run even "better" than when init correctly > transitions into its proper context ! > > I believe in other cases, for some reason that is not evident now, the > context was system_u:system_r:insmod_t with a completely similar effect. > > So, for example, with the wrong init context, not only it is possible to > login into gdm, but also things that were broken with the right init > context works perfectly fine. A few examples: gedit, evince, > gnome-terminal and openoffice refusing to start up without leaving any > trace of denied AVCs in the audit logs and finally no more denied > send_msg with dbus ! > > The output of ps auxZ in this case ? Everything runs in > system_u:system_r:kernel_t:s0 context apart from udev. > > What do you say ? kernel_t is an unconfined domain so that would make sense. not sure if insmod_t is an unconfined_domain as well (can be tested with seinfo -x -aunconfined_domain | grep insmod) > > Is this not a sort of security-flaw ? Someone manages to > relabel /sbin/init and then nobody checks that in enforcing mode init > has effectively re-executed itself in the proper context ? no one, except authorized personnel, should be able to relabel it. >> >>> 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. > > These are some examples of the USER_AVC denials (when init is running in > the proper context and the system has a few problems): > > type=USER_AVC msg=audit(1294930848.646:34): user pid=2243 uid=81 > auid=4294967295 ses=4294967295 > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: > denied { send_msg } for msgtype=method_call > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability > dest=org.freedesktop.Hal spid=2928 tpid=2314 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:hald_t:s0 tclass=dbus : > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' Not sure where you got the idea from that xdm_t is allowed to dbus chat to hald_t in refpolicy, but from my quick inspection it turns out that this access seem to not be allowed (yet) > type=USER_AVC msg=audit(1294930839.360:29): user pid=2243 uid=81 > auid=4294967295 ses=4294967295 > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: > denied { send_msg } for msgtype=method_call > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability > dest=org.freedesktop.Hal spid=2868 tpid=2314 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:hald_t:s0 tclass=dbus : > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' same as above > type=USER_AVC msg=audit(1294930838.020:26): user pid=2243 uid=81 > auid=4294967295 ses=4294967295 > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: > denied { send_msg } for msgtype=method_call > interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability > dest=org.freedesktop.Hal spid=2868 tpid=2314 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:hald_t:s0 tclass=dbus : > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' same as above > > type=USER_AVC msg=audit(1294926149.131:118): user pid=2242 uid=81 > auid=4294967295 ses=4294967295 > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: > denied { send_msg } for msgtype=signal > interface=org.freedesktop.PolicyKit1.Authority member=Changed > dest=org.freedesktop.DBus spid=2613 tpid=2546 > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus : > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' looks like a bug in policy (seem to currently not be allowed in refpolicy) > type=USER_AVC msg=audit(1294948907.764:95): user pid=2242 uid=81 > auid=4294967295 ses=4294967295 > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: > denied { send_msg } for msgtype=method_call > interface=org.freedesktop.DBus.Properties member=GetAll > dest=org.freedesktop.UDisks spid=3567 tpid=3569 > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus : > exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? > terminal=?' currently not allowed in refpolicy > At this point is probably pointless that I bother looking > into /etc/dbus-1/system.d configuration files because it seems something > which depends only on the SELinux policy. yes that is unrelated. You are dealing with refpolicy and you should expect this policy to not be completely tailored to your requirements. >> >> 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 > > Thanks again for offering your advice. > > Regards, > > Guido > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vHHsACgkQMlxVo39jgT8q1QCgrJR7ElPFeRGLhHA4SlCyNkgb okIAoNJEDhYF8iOq9nslphAxFNfKpVH6 =fiBD -----END PGP SIGNATURE-----