From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 9 Oct 2012 09:42:20 -0400 Subject: [refpolicy] [REVIEW REQUEST] Changes to the gnome policy module In-Reply-To: <1349385291.22995.68.camel@d30.localdomain> References: <1349277155-3545-1-git-send-email-dominick.grift@gmail.com> <1349348491.22995.43.camel@d30.localdomain> <506DA2E4.1080004@redhat.com> <1349364272.22995.49.camel@d30.localdomain> <506DC521.30903@redhat.com> <1349372352.22995.51.camel@d30.localdomain> <1349372785.22995.53.camel@d30.localdomain> <506DDDC8.5060602@redhat.com> <1349379031.22995.64.camel@d30.localdomain> <1349385291.22995.68.camel@d30.localdomain> Message-ID: <507429BC.8080200@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 10/04/12 17:14, Dominick Grift wrote: > > > On Thu, 2012-10-04 at 21:30 +0200, Dominick Grift wrote: >> >> On Thu, 2012-10-04 at 15:04 -0400, Daniel J Walsh wrote: >> >>>> >>> >>> Well also the content in this directory does not match correctly for the file >>> context. >>> >>> /run/user/3267/dconf/ versus /home/dwalsh/.config/dconf? >>> >>> Kerberos keyring is there now also there which used to be labeled user_tmp_t. >>> >>> Gkeyringd_tmp_t content is there which also used to be in /tmp. >>> >>> X11-display seems to be moving here also. >>> >> >> .orc and gvfs matches with $HOME. >> >> Nonetheless we should consider things like UBAC, MLS, poly-instantiation >> etc. >> >> I know Redhat does not enable UBAC by default but i am pretty sure she >> would want this technology to be supported at least in a minimal way (or >> let me put it this way: i dont think she would want ubac enablement to >> totally break selinux in redhat distros) to give customers the freedom >> to enable it if they so desire. >> >> UBAC requires that /run/user/UID has the proper selinux identity set, >> else users will not be able to create content in that dir (currently it >> is system_u). >> >> But that aside, upstream will have to deal with that and to diverge >> from, or ignore upstream would be counter productive for all parties >> involved in the long run. >> >> I think that the current labeling may not be good enough >> > > The above comment of me was on second thought probably exaggeration. > > system_u is ubac exempt and user_tmp_t is or can be easily made to > supported poly instantiation. > > i guess it could work unless i am overlooking something My suspicion is that in the long run genhomedircon would need to be enhanced to support a UID substitution like it has a USER substitution. That would yield the most flexibility. Otherwise, in the mean time, labeling /run/user/ as user_tmp_t would probably work. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com