From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 13 Jan 2011 22:37:02 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <4D2F590C.8000005@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> <1294946652.2985.19.camel@tesla.lan> <4D2F590C.8000005@gmail.com> Message-ID: <1294954622.3100.11.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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