From: guido@trentalancia.net (Guido Trentalancia)
Date: Thu, 20 Apr 2017 16:17:03 +0200 (CEST)
Subject: [refpolicy] [PATCH 0/33] description
In-Reply-To: <20170420141003.GB11432@meriadoc.perfinion.com>
References: <1492649990.14733.70.camel@trentalancia.net>
	<808781969.181179.1492690424033@pim.register.it>
	<20170420141003.GB11432@meriadoc.perfinion.com>
Message-ID: <960668182.196968.1492697823367@pim.register.it>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

At the very least, what you suggest doesn't seem correct !

> On the 20th of April 2017 at 16.10 Jason Zaman <jason@perfinion.com> 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
> 
> 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 <refpolicy@oss.tresys.com> 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").
> > > 
> > > Regards,
> > > 
> > > Guido
> > > _______________________________________________
> > > 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