2012-08-01 06:47:05

by sven.vermeulen

[permalink] [raw]
Subject: [refpolicy] kdialog and Chromium

> 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


2012-08-01 14:41:27

by dominick.grift

[permalink] [raw]
Subject: [refpolicy] kdialog and Chromium



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