From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 13 Jan 2011 20:24:12 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <4D2F1C7B.5040206@gmail.com> 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> <4D2F1C7B.5040206@gmail.com> Message-ID: <1294946652.2985.19.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Dominick ! Apparently the thread and your latest reply got splitted in two messages with the same subject. Let's just follow up with this message which has the original Reference header. On Thu, 13/01/2011 at 16.38 +0100, Dominick Grift wrote: > >> 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) Yes, insmod_t is also an unconfined domain in the refpolicy-2.20101213. > > 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. Yes, I know this. But to me it still appears as a weak point, which should be tackled in some way sooner or later. Also, consider that mislabelling in not uncommon and can happen for a variety of reasons without necessarily showing many signs. System-security depending just on 1 correct label, 1 critical point with no further checks doesn't sound quite right... > >>> 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 Currently not allowed and looks like a bug in policy. Should we do something about it ? > You are dealing with refpolicy and you should expect this policy to not > be completely tailored to your requirements. Yes, I know that. But because my requirements are just those of a quite standard modern Linux system, we should probably elaborate further on what is missing. I would probably be able to spare some of my time for example. Nobody else interested in this thread and the opportunity given to improve refpolicy ? Regards, Guido