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

[domg472@gmail.com (Dominick Grift)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2011 10:37 PM, Guido Trentalancia wrote:
> Hello again !
> 
> On Thu, 13/01/2011 at 20.57 +0100, Dominick Grift wrote:
>>>>> 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.
>>
>> Its not that easy. Reference policy needs to stay a general purpose
>> policy. Each submitted line of policy needs to be judged in that light.
> 
> Yes. But again, the system on which it is being tested is a general
> purpose, plain, standard Linux system built from plain upstream
> components. So, I can't see how the above is not relevant to refpolicy.

Alright, well you can work with refpolicy to get your changes upstreamed.

>>> Nobody else interested in this thread and the opportunity given to
>>> improve refpolicy ?
>>
>> These rules are probably already in Fedora and Fedora works pretty
>> closely with refpolicy to get its stuff upstreamed (redhat values
>> working to get their stuff upstreamed) Refpolicy probably hasnt adopted
>> it yet becuase a) it wasnt approved. b) the context of why it is
>> required was missing. b) the patch submitted wasnt complete. c) some
>> other reason (like time contraints).
>>
>> But sure, i encourage you to try and get some of your modifications
>> upstreamed.
> 
> I have never done that before. Left completely alone, I am not sure what
> will eventually come out. But I shall probably give it a try...
> 

You have to start somewhere.

>> I also run a custom policy that is based off of refpolicy. you can find
>> it here:
>>
>> http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=summary
> 
> I'll have a look at it and see if anything can be adapted to sort out
> the problem with dbus messages.

Might be better to look at fedora's policy.

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=summary

> But in general for USER_AVCs there is nothing like audit2allow that can
> be used to ease the job ?

audit2allow can also be used for these dbus AVC' s sure. But if you want
this stuff upstreamed then you will have to play by upstreams rules
(style rules)

> 
>> However this policy is unfortunately also not suitable to get upstreamed
>> because it has distinct properties and security goals (thus not
>> applicable to the general purpose reference policy)
>>
>>> Regards,
>>>
>>> Guido
> 
> Thanks. Guido
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0vcecACgkQMlxVo39jgT/KBwCfTSaGQiSG844hIE8SAcBP3F+C
cPUAoNLkzq+ZgL4Y2tigWyYRdcGjluCF
=KvBJ
-----END PGP SIGNATURE-----