From: domg472@gmail.com (Dominick Grift) Date: Thu, 13 Jan 2011 16:45:28 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <1294932084.3153.26.camel@tesla.lan> References: <1294932084.3153.26.camel@tesla.lan> Message-ID: <4D2F1E18.9000105@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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. Unless you are familiar with policy design/implementation, it is probably best to not use plain reference policy. > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vHhgACgkQMlxVo39jgT+YwQCgmtq/W3hWHOdsJbmQQYng/6BG qNkAoLkPFCf2kHI+aLZp3fBbxk7twoZ0 =nsDh -----END PGP SIGNATURE-----