[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[domg472@gmail.com (Dominick Grift)]

-----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-----