From: dominick.grift@gmail.com (Dominick Grift) Date: Thu, 04 Oct 2012 23:14:51 +0200 Subject: [refpolicy] [REVIEW REQUEST] Changes to the gnome policy module In-Reply-To: <1349379031.22995.64.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> Message-ID: <1349385291.22995.68.camel@d30.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 >