[refpolicy] kdialog and Chromium

[refpolicy] kdialog and Chromium

[Russell Coker]

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/

[refpolicy] kdialog and Chromium

[Sven Vermeulen]

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.

[refpolicy] kdialog and Chromium

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] kdialog and Chromium

[Sven Vermeulen]

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

[refpolicy] kdialog and Chromium

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] kdialog and Chromium

[Sven Vermeulen]

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

[refpolicy] kdialog and Chromium

[Dominick Grift]

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

[refpolicy] kdialog and Chromium

[Dominick Grift]

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
> 
> 

[refpolicy] kdialog and Chromium

[Sven Vermeulen]

> On Wed, 2012-08-01 at 00:59 +0200, Dominick Grift wrote:
> 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.

User content is a generic type and is currently used for *all* that users'
content. In my opinion, it is like we would only have var_t and nothing
else.
Confinement of the userspace is a different animal than confinement of the
services or daemons - the latter have a much better defined behavior than
users.

However, that doesn't mean we can't provide better confinement for user-ran
applications too. My first focus now is to handle browsers (individually)
and allow administrators to define the access for these browsers.

I don't agree with your viewpoint that browsers need read/write access to
all content, but I don't have to. SELinux supports booleans, and I'm going
to use that to allow administrators to define the different 'levels' of
access.

chromium_read_user_content (default: true)
chromium_manage_user_content (default: false)

With these booleans you have the ability to control for your situation
what you believe matches your expectations (namely read/write access to
user content) whereas I can limit the access to just the downloads stuff.

I tend to use SELinux booleans as the USE flags in Gentoo: users (admins)
set them according to their beliefs and needs, and the system adapts to
it.

Wkr,
Sven Vermeulen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120801/c29673f6/attachment.html 

[refpolicy] kdialog and Chromium

[Dominick Grift]

On Wed, 2012-08-01 at 08:47 +0200, Sven Vermeulen wrote:
> > On Wed, 2012-08-01 at 00:59 +0200, Dominick Grift wrote:
> > 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.
> 
> User content is a generic type and is currently used for *all* that
> users'
> content. In my opinion, it is like we would only have var_t and
> nothing else.

If you are going to compare it to for example var_t then the generic
type for user content is user_home_dir_t in my view.

But you cannot compare it

> Confinement of the userspace is a different animal than confinement of
> the
> services or daemons - the latter have a much better defined behavior
> than
> users.
> 
> However, that doesn't mean we can't provide better confinement for
> user-ran
> applications too. My first focus now is to handle browsers
> (individually)
> and allow administrators to define the access for these browsers.
> 

Browsers are complex beasts. They can run all kinds of things on behalf
of the user. Consider media players, plugins, mail clients etc. To
confine a browser in my view means to confine any of these user
applications. Needless to say that all these individual applications
also interact with and operate on other dependencies.

> I don't agree with your viewpoint that browsers need read/write access
> to
> all content, but I don't have to. SELinux supports booleans, and I'm
> going
> to use that to allow administrators to define the different 'levels'
> of
> access.
> 
> chromium_read_user_content (default: true)
> chromium_manage_user_content (default: false)
> 
> With these booleans you have the ability to control for your situation
> what you believe matches your expectations (namely read/write access
> to
> user content) whereas I can limit the access to just the downloads
> stuff.
> 
> I tend to use SELinux booleans as the USE flags in Gentoo: users
> (admins)
> set them according to their beliefs and needs, and the system adapts
> to
> it.
> 
> Wkr,
> Sven Vermeulen
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy