From: guido@trentalancia.net (Guido Trentalancia) Date: Sat, 22 Apr 2017 13:50:06 +0200 Subject: [refpolicy] [PATCH 0/33] description In-Reply-To: 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: <014CCF29-92AC-489E-8248-B681BFF663DA@trentalancia.net> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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... Regards, Guido 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 >> _______________________________________________ >> refpolicy mailing list >> refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy >_______________________________________________ >refpolicy mailing list >refpolicy at oss.tresys.com >http://oss.tresys.com/mailman/listinfo/refpolicy