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

[domg472@gmail.com (Dominick Grift)]

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