From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 13 Jan 2011 20:49:29 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <4D2F1E18.9000105@gmail.com> References: <1294932084.3153.26.camel@tesla.lan> <4D2F1E18.9000105@gmail.com> Message-ID: <1294948169.2985.4.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Dominick ! On Thu, 13/01/2011 at 16.45 +0100, Dominick Grift wrote: > -----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. 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 ? 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 > > -----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----- > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy >