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

[guido@trentalancia.com (Guido Trentalancia)]

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.

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

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

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

> 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