Currently on Debian/Wheezy it's impossible to download files in Chromium when
you are running a KDE session.
Chromium launches kdialog to display the dialog box to ask where the file
should be saves. kdialog wants to write to files such as
~/.kde/share/config/kdebugrc.lock which isn't permitted for mozilla_t.
One possibility that occurs to me is to have kdialog transition to user_t.
Transitioning from mozilla_t isn't generally a good thing, and breaks the case
of running mozilla_t from multiple user domains (multiple user domains is
essentially a broken feature of the policy anyway).
Apart from modifying kdialog to not depend on the ability to write to
kdebugrc.lock what can I do to solve this?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Fri, Jul 27, 2012 at 04:14:43PM +1000, Russell Coker wrote:
> Currently on Debian/Wheezy it's impossible to download files in Chromium when
> you are running a KDE session.
>
> Chromium launches kdialog to display the dialog box to ask where the file
> should be saves. kdialog wants to write to files such as
> ~/.kde/share/config/kdebugrc.lock which isn't permitted for mozilla_t.
>
> One possibility that occurs to me is to have kdialog transition to user_t.
> Transitioning from mozilla_t isn't generally a good thing, and breaks the case
> of running mozilla_t from multiple user domains (multiple user domains is
> essentially a broken feature of the policy anyway).
>
> Apart from modifying kdialog to not depend on the ability to write to
> kdebugrc.lock what can I do to solve this?
Russel, sorry for sending you previous mails privately, wasn't my intention.
As I said, I'm working on a (separate[1]) domain for chromium and hit similar
issues too (for instance when accessing ~/.pki) since I am trying to get the
browsers running without requiring access to user_home_t stuff.
Perhaps we can allow for a sharable lock file type (kde_lock_t) and allow
the domain search rights in the kde_home_t stuff (I'm assuming these are the
domains, I don't have any kde_* stuff here) and an automated file transition
when a file with the name "kdebugrc.lock" is written in kde_home_t to
kde_lock_t ?
Wkr,
Sven Vermeulen
[1] Chromium itself can be built with SELinux-enabled, but then requires
that the policy supports a domain called chromium_renderer_t (which it
dynamically transitions to). It doesn't make sense to include this in the
mozilla_t domain.
Also, many companies have different policies for the browsers: the globally
supported browser has more rights (more open) whereas the other browsers can
only be used in a limited extend. I tend to use booleans to toggle this, but
then we can't use a global domain since booleans affect all browsers in that
domain.
On 07/27/12 05:12, Sven Vermeulen wrote:
> On Fri, Jul 27, 2012 at 04:14:43PM +1000, Russell Coker wrote:
>> Currently on Debian/Wheezy it's impossible to download files in Chromium when
>> you are running a KDE session.
>>
>> Chromium launches kdialog to display the dialog box to ask where the file
>> should be saves. kdialog wants to write to files such as
>> ~/.kde/share/config/kdebugrc.lock which isn't permitted for mozilla_t.
>>
>> One possibility that occurs to me is to have kdialog transition to user_t.
>> Transitioning from mozilla_t isn't generally a good thing, and breaks the case
>> of running mozilla_t from multiple user domains (multiple user domains is
>> essentially a broken feature of the policy anyway).
>>
>> Apart from modifying kdialog to not depend on the ability to write to
>> kdebugrc.lock what can I do to solve this?
>
> Russel, sorry for sending you previous mails privately, wasn't my intention.
>
> As I said, I'm working on a (separate[1]) domain for chromium and hit similar
> issues too (for instance when accessing ~/.pki) since I am trying to get the
> browsers running without requiring access to user_home_t stuff.
>
> Perhaps we can allow for a sharable lock file type (kde_lock_t) and allow
> the domain search rights in the kde_home_t stuff (I'm assuming these are the
> domains, I don't have any kde_* stuff here) and an automated file transition
> when a file with the name "kdebugrc.lock" is written in kde_home_t to
> kde_lock_t ?
At the moment, I don't have any suggestions beyond something like this. Not unless you want a conditional for writing out files to the home dir.
> [1] Chromium itself can be built with SELinux-enabled, but then requires
> that the policy supports a domain called chromium_renderer_t (which it
> dynamically transitions to). It doesn't make sense to include this in the
> mozilla_t domain.
Is chromium_renderer_t hard coded into Chromium or does it sanely expect an appconfig file (like initrc_context or userhelper_context)?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Tue, Jul 31, 2012 at 02:32:39PM -0400, Christopher J. PeBenito wrote:
> On 07/27/12 05:12, Sven Vermeulen wrote:
> > As I said, I'm working on a (separate[1]) domain for chromium and hit similar
> > issues too (for instance when accessing ~/.pki) since I am trying to get the
> > browsers running without requiring access to user_home_t stuff.
> >
> > Perhaps we can allow for a sharable lock file type (kde_lock_t) and allow
> > the domain search rights in the kde_home_t stuff (I'm assuming these are the
> > domains, I don't have any kde_* stuff here) and an automated file transition
> > when a file with the name "kdebugrc.lock" is written in kde_home_t to
> > kde_lock_t ?
>
> At the moment, I don't have any suggestions beyond something like this. Not
> unless you want a conditional for writing out files to the home dir.
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.
> > [1] Chromium itself can be built with SELinux-enabled, but then requires
> > that the policy supports a domain called chromium_renderer_t (which it
> > dynamically transitions to). It doesn't make sense to include this in the
> > mozilla_t domain.
>
> Is chromium_renderer_t hard coded into Chromium or does it sanely expect an
> appconfig file (like initrc_context or userhelper_context)?
It's currently hardcoded, but I think it is because of inexperience:
~$ grep -HR chromium_renderer_t ~/Development/build/tmp/chromium-20.0.1132.43/
content/browser/zygote_main_linux.cc: SELinuxTransitionToTypeOrDie("chromium_renderer_t");
Wkr,
Sven Vermeulen
On 07/31/12 15:13, Sven Vermeulen wrote:
> On Tue, Jul 31, 2012 at 02:32:39PM -0400, Christopher J. PeBenito wrote:
>> On 07/27/12 05:12, Sven Vermeulen wrote:
>>> As I said, I'm working on a (separate[1]) domain for chromium and hit similar
>>> issues too (for instance when accessing ~/.pki) since I am trying to get the
>>> browsers running without requiring access to user_home_t stuff.
>>>
>>> Perhaps we can allow for a sharable lock file type (kde_lock_t) and allow
>>> the domain search rights in the kde_home_t stuff (I'm assuming these are the
>>> domains, I don't have any kde_* stuff here) and an automated file transition
>>> when a file with the name "kdebugrc.lock" is written in kde_home_t to
>>> kde_lock_t ?
>>
>> At the moment, I don't have any suggestions beyond something like this. Not
>> unless you want a conditional for writing out files to the home dir.
>
> 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.
>>> [1] Chromium itself can be built with SELinux-enabled, but then requires
>>> that the policy supports a domain called chromium_renderer_t (which it
>>> dynamically transitions to). It doesn't make sense to include this in the
>>> mozilla_t domain.
>>
>> Is chromium_renderer_t hard coded into Chromium or does it sanely expect an
>> appconfig file (like initrc_context or userhelper_context)?
>
> It's currently hardcoded, but I think it is because of inexperience:
>
> ~$ grep -HR chromium_renderer_t ~/Development/build/tmp/chromium-20.0.1132.43/
> content/browser/zygote_main_linux.cc: SELinuxTransitionToTypeOrDie("chromium_renderer_t");
:(
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
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.
Wkr,
Sven Vermeulen
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
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
>
>