From: guido@trentalancia.net (Guido Trentalancia) Date: Sat, 06 May 2017 19:10:54 +0200 Subject: [refpolicy] [PATCH 0/33] description In-Reply-To: <9A0DFADE-16B3-4900-8BF6-620FEE8BE0AF@trentalancia.net> 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> <9A0DFADE-16B3-4900-8BF6-620FEE8BE0AF@trentalancia.net> Message-ID: <994D434F-6D3C-4450-843B-DB47F7EB84BC@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com I forgot to add: Of course, the configuration can be automated on distributions... On the 6th of May 2017 19:00:09 CEST, Guido Trentalancia via refpolicy wrote: >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); For maximum usability, distributions can turn the corresponding boolean to true upon installing a given daemon or application and turn it to false upon deinstalling it (e.g. from the .spec file on distributions using RPM or similar). At any time, end-users can fine-tune the above using setsebool manually to maximize user data confidentiality instead of usability. >- 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. > >_______________________________________________ >refpolicy mailing list >refpolicy at oss.tresys.com >http://oss.tresys.com/mailman/listinfo/refpolicy