From: sven.vermeulen@siphos.be (Sven Vermeulen) Date: Sat, 22 Apr 2017 11:13:53 +0200 Subject: [refpolicy] [PATCH 0/33] description In-Reply-To: <342768044.208111.1492728614697@pim.register.it> 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> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy