From: domg472@gmail.com (Dominick Grift) Date: Thu, 13 Jan 2011 22:43:03 +0100 Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages In-Reply-To: <1294954622.3100.11.camel@tesla.lan> 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> <1294954622.3100.11.camel@tesla.lan> Message-ID: <4D2F71E7.7030901@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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-----