From: guido@trentalancia.net (Guido Trentalancia) Date: Sat, 06 May 2017 19:00:09 +0200 Subject: [refpolicy] [PATCH 0/33] description In-Reply-To: <10734812-f327-89ed-5e7e-327eaea7b8c5@ieee.org> References: <1492649990.14733.70.camel@trentalancia.net> <808781969.181179.1492690424033@pim.register.it> <20170420141003.GB11432@meriadoc.perfinion.com> <960668182.196968.1492697823367@pim.register.it> <342768044.208111.1492728614697@pim.register.it> <014CCF29-92AC-489E-8248-B681BFF663DA@trentalancia.net> <8bc4f938-ee7d-76e1-cfe0-482674460e2e@ieee.org> <10734812-f327-89ed-5e7e-327eaea7b8c5@ieee.org> Message-ID: <9A0DFADE-16B3-4900-8BF6-620FEE8BE0AF@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello. Conceptually the patch that I submitted can be synthesised as follows: - never allow any domain to read or write user home directories' content unless a specific "enable_homedir" boolean is set to true (default value is false, for all daemons and applications); - always allow all domains that were previously allowed to read and/or write user home directories' content to read and/or write the "Download" subdirectory *only* (this is treated as a shared parking area); - the only exception to the first above rule is when a domain *absolutely* needs to read or write the user home directories' content for working properly (most notably, gnome-shell needs to manage and execute temporary files in the user home directory; I don't think there are other exceptions, apart from user management applications that need to create user home directories NOT content). I hope this helps. Regards, Guido On the 6th of May 2017 18:36:08 CEST, Chris PeBenito via refpolicy wrote: >On 05/06/2017 07:59 AM, Sven Vermeulen via refpolicy wrote: >> On Sun, Apr 23, 2017 at 3:14 PM, Chris PeBenito via refpolicy >> wrote: >>> On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy wrote: >>>> The patchset that I have posted the other day is ready to use, now. >>>> >>>> How comes these other changes, that you say are equivalent, have >not been merged yet? >>>> >>>> Christopher has already decided to apply the patch that you >mentioned, I hope there will be the same functionality implemented at >least before next release... >>> >>> I've given feedback several times. I'm not sure what happened, and >I >>> can't remember if we couldn't come to a conclusion or if it simply >fell >>> off my plate. >> >> I think that's my fault. The last feedback was that you weren't sure >> that the approach needs its own module or not. Remember, Gentoo has >> moved those definitions inside its own module (xdg.*) to refer to the >> base specification where those locations have been defined. This is >> for a couple of reasons: to not make userdomain larger than it is >> already, to make use of the modularity that refpolicy provides, and >to >> facilitate some compatibility (no xdg module, then the locations >> remain user_home_t for instance). >> >> A year or two later, a separate xdg module was suggested by Dominick >> as well (with similar concept as Gentoo has), but it fell through the >> cracks too (no discussion on it [1]). >> >> [1] >http://oss.tresys.com/pipermail/refpolicy/2013-November/006621.html >> >> So one of the decisions we need to take is if a separate module is >> warranted or not. This can go either way, and if you or the community >> at large prefers to put it in the userdomain, then I can agree to >> follow it - I might not fully stand behind it, but this is a >community >> effort after all, and I too prefer to get things forward (so, >> apologies that I didn't follow up then). >> >> My suggestion would be as follows: >> >> I'll go through Guido's patch and see if there are any *conceptual* >> differences between his patch and Gentoo's approach. If there are, >> we'll discuss them here to see what is the best way forward. If >> Gentoo's conceptual design is more preferred then we'll probably base >> it on Gentoo's current policy code base. If Guido's is preferential >> then we start off with Guido's. >> >> Once the conceptual differences have been resolved (or there weren't >> to begin with), then the next step would be to publish the patch >round >> again (whatever based upon) with the merged changes from both sets >(be >> it Gentoo's or Guido's). As Jason already mentioned - yes, this is a >> big patch, so it also makes sense to do this in a step-wise approach >> rather than one big patch set. >> >> Is that feasible for you guys? I know I haven't been around/active >for >> a long time but that's about to change ;-) > > >Makes sense to me.