From: domg472@gmail.com (Dominick Grift) Date: Thu, 13 Jan 2011 19:51:44 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <1294948169.2985.4.camel@tesla.lan> References: <1294932084.3153.26.camel@tesla.lan> <4D2F1E18.9000105@gmail.com> <1294948169.2985.4.camel@tesla.lan> Message-ID: <4D2F49C0.6050708@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 08:49 PM, Guido Trentalancia wrote: > Hello Dominick ! > > On Thu, 13/01/2011 at 16.45 +0100, Dominick Grift wrote: > On 01/13/2011 04:21 PM, Guido Trentalancia wrote: >>>> Hello again Dominick ! > > You should, if possible, use policy that is distributed by your distro. > >> I am not using any of the publicly available distribution. I have >> created my own installation. Therefore I would need to start from >> scratch and use refpolicy. > > refpolicy is a general purpose base policy. Ir is not tailored to any > specific distro. It serves as a base for distribution to base their > policy off. > >> Yes, I can start developing a customised policy if time allows but I >> need to start with refpolicy first. > > Unless you are familiar with policy design/implementation, it is > probably best to not use plain reference policy. > >> Again, see above. > >> But then, what is your comment on the USER_AVC logs that I posted ? my comment is that this functionality is currently not supported by reference policy and that i would probably extend/modify reference policy to allow this access. >> Regards, > >> Guido > >>>> 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 ? >>>> >>>> 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 ? >>>> >>>>>> 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=?' >>>> >>>> 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=?' >>>> >>>> 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=?' >>>> >>>> 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=?' >>>> >>>> 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=?' >>>> >>>> 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. >>>> >>>>> 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 >>>> >>>> _______________________________________________ >>>> 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/ iEYEARECAAYFAk0vSb8ACgkQMlxVo39jgT97RwCfWxg2AFr4V5Jud4OoIgBHSn/P hHMAoKxzUDYE2JhuFD9K87dgg+2BkjHh =DonV -----END PGP SIGNATURE-----