From: dominick.grift@gmail.com (Dominick Grift)
Date: Wed, 01 Aug 2012 00:59:47 +0200
Subject: [refpolicy] kdialog and Chromium
In-Reply-To: <20120731192849.GD17454@siphos.be>
References: <201207271614.43908.russell@coker.com.au>
	<20120727091218.GB13778@siphos.be> <501824C7.6020505@tresys.com>
	<20120731191312.GB17454@siphos.be> <5018308B.4040008@tresys.com>
	<20120731192849.GD17454@siphos.be>
Message-ID: <1343775587.23552.4.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On Tue, 2012-07-31 at 21:28 +0200, Sven Vermeulen wrote:
> On Tue, Jul 31, 2012 at 03:22:51PM -0400, Christopher J. PeBenito wrote:
> > > I'm actually more inclined (and am trying to) support a downloads type where
> > > browsers have the necessary rights to, but nowhere else. Browsers are a too
> > > public attack vector lately so the less I need it to write (or even read)
> > > user home content the better.
> > 
> > I can go for that solution too... like a mozilla_downloads_t, user_downloads_t, or similar.
> 
> I'm currently looking at the XDG patch I mentioned a while back. The XDG
> standard defines some user-related locations (Downloads, Videos, Pictures)
> which I currently have labeled xdg_downloads_home_t (etc.) and marked as
> customizable (btw, took me a while to realise it is sufficient to just add 
> "# customizable" after the type declaration to do so) so that users can mark
> it easily themselves.
> 
> My XDG definitions:
> 
> ~$ cat ~/.config/user-dirs.dirs 
> XDG_DESKTOP_DIR="$HOME/Desktop"
> XDG_DOWNLOAD_DIR="$HOME/Downloads"
> XDG_TEMPLATES_DIR="$HOME/"
> XDG_PUBLICSHARE_DIR="$HOME/Public"
> XDG_DOCUMENTS_DIR="$HOME/Documents"
> XDG_MUSIC_DIR="$HOME/Music"
> XDG_PICTURES_DIR="$HOME/Pictures"
> XDG_VIDEOS_DIR="$HOME/Videos"
> 
> Hence, xdg_downloads_home_t, xdg_videos_home_t, xdg_pictures_home_t and
> xdg_music_home_t. Don't immediately see a need for the other ones though.

This is generic user content we have a type for that: user_home_t.

We just need to confine all user application config, data and cache
content, or at least as much as possible.

browsers (and many other user agents) need to be able to read/write
generic user content. They dont need access to config, data or cache
content of programs they dont have business with.

> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy