From: pebenito@ieee.org (Chris PeBenito) Date: Sun, 23 Apr 2017 09:14:00 -0400 Subject: [refpolicy] [PATCH 0/33] description In-Reply-To: <014CCF29-92AC-489E-8248-B681BFF663DA@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> Message-ID: <8bc4f938-ee7d-76e1-cfe0-482674460e2e@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy wrote: > Hello. > > 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. > On the 22nd April 2017 11:13:53 CEST, Sven Vermeulen via refpolicy wrote: >> We've bundled those in the xdg policy module, as a reference to the >> XDG Base Directory Specification which is somewhat a descriptive >> document on the various locations included in the patch. >> >> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/contrib/xdg.if >> >> We make a distinction between the "generic" directories (like >> ~/.local/share = xdg_data_home_t) versus application-specific ones >> (like ~/.local/share/xorg = xserver_xdg_data_home_t). In the >> interfaces (as mentioned above) applications can then get either >> rights on the generic ones, or all (xdg_read_data_home_files() vs >> xdg_read_all_data_home_files() as examples). >> >> The idea is the same as you had - not all applications need access to >> generic user content. Especially the browsers, as those are a main >> attack vector nowadays, but it of course extends to others as well. >> >> As each user has a different approach or use case, we then make it >> often optional (through booleans) if an application domain can or >> can't access user home directories. This is handled through the >> userdom_user_content_access_template() which generates, for >> application domains, the *_read_generic_user_content, >> *_read_all_user_content, *_manage_generic_user_content and >> *_manage_all_user_content booleans. >> >> To accomplish that, we introduced attributes that are assigned to user >> content (user_home_content_type) to toggle access to either the >> user_home_t type or the wider set. >> >> Hope that helps a bit. >> >> Wkr, >> Sven Vermeulen >> >> On Fri, Apr 21, 2017 at 12:50 AM, Guido Trentalancia via refpolicy >> wrote: >>> Hello. >>> >>> I have just browsed the following website: >>> >>> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/log/ >>> >>> which should belong to the Gentoo distribution, but I couldn't find >> any reference to a similar patch... >>> >>> I am not sure we are talking about the same kind of patch ! >>> >>> Guido >>> >>>> On the 21st of April 2017 at 0.20 Chris PeBenito >> wrote: >>>> >>>> >>>> On 04/20/2017 10:17 AM, Guido Trentalancia via refpolicy wrote: >>>>> At the very least, what you suggest doesn't seem correct ! >>>>> >>>>>> On the 20th of April 2017 at 16.10 Jason Zaman >> wrote: >>>>>> >>>>>> >>>>>> Whoa whoa. this is a huuuuge patchset. If we're gonna take >> something >>>>>> like this upstream can we instead take the gentoo stuff? we've >> had a >>>>>> cleaner version of this for ages and its well tested so i'd >> rather >>>>>> upstream that instead first then apply any remaining things on >> top of >>>>>> it? >>>>>> >>>>>> -- Jason >>>> >>>> I'm afraid I have to agree with Jason on this. The Gentoo guys have >>>> been working this for quite some time. >>>> >>>> >>>>>> On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via >> refpolicy wrote: >>>>>>> I forgot to add: the Download directory is always writable and >> can be used as a shared "parking" area for all sort of files (not >> necessarily only those that are downloaded from the network). >>>>>>> >>>>>>> Files that are considered "safe" after inspection can be picked >>from the shared parking area and moved elsewhere within the home >> directory (or outside of it). >>>>>>> >>>>>>> Applications that do not have a corresponding policy module run >> as "user_u" and therefore always have full read/write access to the >> whole home directory, that's why it is important to confine as much >> applications as possible. >>>>>>> >>>>>>> A couple of patches in this set (the 22nd and the 25th) wrongly >> bring "/34" in the email subject: this is a mistake, please read "/33". >>>>>>> >>>>>>> I hope you find the patchset an useful step towards assuring >> user data confidentiality. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Guido >>>>>>> >>>>>>>> On the 20th of April 2017 at 2.59 Guido Trentalancia via >> refpolicy wrote: >>>>>>>> >>>>>>>> >>>>>>>> This patchset aims to ensure user data confidentiality by >> curbing on >>>>>>>> userdomain file read and/or write permissions for all >> applications and >>>>>>>> daemons that potentially deal with such files and directories. >>>>>>>> >>>>>>>> Several modules would greatly benefit from further testing. >>>>>>>> >>>>>>>> Where possible a boolean has been introduced to revert the less >>>>>>>> restrictive and more risky behavior (by setting it to "true"). -- Chris PeBenito