From: dominick.grift@gmail.com (Dominick Grift) Date: Wed, 01 Aug 2012 01:20:37 +0200 Subject: [refpolicy] kdialog and Chromium In-Reply-To: <1343775587.23552.4.camel@d30.localdomain> 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> <1343775587.23552.4.camel@d30.localdomain> Message-ID: <1343776837.23552.20.camel@d30.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 2012-08-01 at 00:59 +0200, Dominick Grift wrote: > > 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. > In a perfect freedesktop home directory all app config, data and cache content is in ~/.config, ~/.cache and /.local/share. That in my view is what we should focus on first. Then all the app config, data and cache content that is not currently in a proper freedesktop xdg location. Many user applications need full access to generic user home content. Consider you uploading a photo from ~/Pictures to picassa , a ~/Videos to youtube or downloading some content to ~/Downloads with your browser or as an attachment with your mail client or whatever Think carefully about this please. It is just not that easy to do. To do this properly or at least build a solid foundation you need to confine the layer between the user, user apps and the system. Namely the Desktop environment. This will introduce other issues, where users run apps that run apps that run apps on your behalf. How to tell SELinux on whos behalf the app runs? (user role prefixed types is one way) I believe its better to think about all these issues first and get some consensus on that. It might save some work and time in the long run. > > Wkr, > > Sven Vermeulen > > _______________________________________________ > > refpolicy mailing list > > refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > >