Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Hardened

www-client/chromium SELinux sandbox

 

 

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded


phajdan.jr at gentoo

Apr 10, 2012, 4:11 AM

Post #1 of 7 (745 views)
Permalink
www-client/chromium SELinux sandbox

I'm experimenting with Chromium SELinux sandbox
(<http://code.google.com/p/chromium/wiki/LinuxSandboxing>) and came up
with a working policy module (attached).

Note that for that to be effective one has to compile chromium with
-Dselinux=1 gyp flag, and I've not yet committed such change to CVS
(waiting for 20.x dev channel release, so that it has a lot of testing
before unmasking).

How does the attached policy look to you? (I'm SELinux newbie, although
I probably know Chromium pretty well as its developer and packager)

You can also compare that with policy module written for Chromium by
another Chromium developer in 2010:
<http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/selinux/chromium-browser.te?view=markup>

What are the next steps to add this policy to Gentoo?
Attachments: chromium-browser.te (1.23 KB)
  signature.asc (0.20 KB)


swift at gentoo

Apr 10, 2012, 10:46 AM

Post #2 of 7 (725 views)
Permalink
Re: www-client/chromium SELinux sandbox [In reply to]

On Tue, Apr 10, 2012 at 01:11:36PM +0200, "Paweł Hajdan, Jr." wrote:
> I'm experimenting with Chromium SELinux sandbox
> (<http://code.google.com/p/chromium/wiki/LinuxSandboxing>) and came up
> with a working policy module (attached).
>
> Note that for that to be effective one has to compile chromium with
> -Dselinux=1 gyp flag, and I've not yet committed such change to CVS
> (waiting for 20.x dev channel release, so that it has a lot of testing
> before unmasking).
>
> How does the attached policy look to you? (I'm SELinux newbie, although
> I probably know Chromium pretty well as its developer and packager)
>
> You can also compare that with policy module written for Chromium by
> another Chromium developer in 2010:
> <http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/linux/selinux/chromium-browser.te?view=markup>
>
> What are the next steps to add this policy to Gentoo?

Hi Paweł,

The policy itself is currently written (or generated?) with raw allow rules
towards domains not defined by the policy module itself. For instance:

allow chromium_renderer_t urandom_device_t:chr_file { getattr open read };

The policies we strive to support are based on the naming and style
conventions used by the reference policy, so that we can easily forward them
to their repository. This has the advantages that, if accepted,

1. the names used are globally set, so no collisions can occur with
possible future releases of other modules,
2. the policy code itself will be reviewed by more experts, but also better
maintained, as it will be used by other distributions (and contributors)
as well

The above allow rule would probably look like:
dev_read_urand(chromium_renderer_t)
which, given prior experience, probably means you also want (or need) to
dev_read_rand(chromium_renderer_t)
as well ;-)

Do you feel up to updating the policy to reflect the style of refpolicy? If
not, I don't mind taking a stab at it myself.

However, besides the style, it also looks like the module is quite
incomplete. It only defines the chromium_renderer_t, but how would chrome
ever be able to "transition" to this domain? There is no transition rule
declared, nor any files that could behave as entry points for the domain.

I would also expect that, if it is for chromium, there would be a chromium_t
domain as well. Or in other words:

- a user calls chromium (labeled "chromium_exec_t")
- a transition occurs from user_t to chromium_t
- chromium calls some binary for rendering (or is SELinux-aware and
does it by itself)
- a transition occurs from chromium_t to chromium_renderer_t
- etc.

The use of "dyntransition" is frowned upon as it is much more "lax" than a
regular transition.

Wkr,
Sven Vermeulen


phajdan.jr at gentoo

Apr 10, 2012, 1:10 PM

Post #3 of 7 (722 views)
Permalink
Re: www-client/chromium SELinux sandbox [In reply to]

On 4/10/12 7:46 PM, Sven Vermeulen wrote:
> The policy itself is currently written (or generated?) with raw allow rules

Thank you for taking a look.

The policy is written from scratch, using audit2allow to add rules, but
I was careful to always test in enforcing mode, and to only grant what's
needed (i.e. verifying that without given rule the browser would break).

> which, given prior experience, probably means you also want (or need) to
> dev_read_rand(chromium_renderer_t)
> as well ;-)

dev_read_rand won't be needed. It's quite interesting, because I was
writing that part of code when porting the browser to Linux. It only
uses /dev/urandom.

> Do you feel up to updating the policy to reflect the style of refpolicy? If
> not, I don't mind taking a stab at it myself.

See attached version, I updated all places I could and verified it still
works.

Note that to test you'd need SELinux-aware chromium, which I've not yet
checked to cvs (I'll do that as soon as upstream releases official 20.x
version).

> However, besides the style, it also looks like the module is quite
> incomplete. It only defines the chromium_renderer_t, but how would chrome
> ever be able to "transition" to this domain? There is no transition rule
> declared, nor any files that could behave as entry points for the domain.

The browser uses setcon, see SELinuxTransitionToTypeOrDie in Chromium
codebase (cs.chromium.org),
<http://code.google.com/searchframe#OAMlx_jo-ck/src/content/browser/zygote_main_linux.cc&exact_package=chromium&q=setcon&type=cs&l=72>

> I would also expect that, if it is for chromium, there would be a chromium_t
> domain as well. Or in other words:
>
> - a user calls chromium (labeled "chromium_exec_t")
> - a transition occurs from user_t to chromium_t
> - chromium calls some binary for rendering (or is SELinux-aware and
> does it by itself)
> - a transition occurs from chromium_t to chromium_renderer_t
> - etc.

Chromium can be compiled to be SELinux-aware, and it forks itself (and
doesn't call exec - so that the underlying files can be updated in-place
without disrupting running browsers; this is because Chromium has
multi-process architecture and browser<->renderer IPC protocol changes
between versions).

> The use of "dyntransition" is frowned upon as it is much more "lax" than a
> regular transition.

I've heard about that. I'm not aware of any better option for chromium
though, especially that it can't really use exec, only fork.
Attachments: chromium-browser.te (1.06 KB)
  signature.asc (0.20 KB)


phajdan.jr at gentoo

Apr 11, 2012, 10:09 PM

Post #4 of 7 (729 views)
Permalink
Re: www-client/chromium SELinux sandbox [In reply to]

On 4/10/12 10:10 PM, "Paweł Hajdan, Jr." wrote:
> Chromium can be compiled to be SELinux-aware, and it forks itself (and
> doesn't call exec - so that the underlying files can be updated in-place
> without disrupting running browsers; this is because Chromium has
> multi-process architecture and browser<->renderer IPC protocol changes
> between versions).

chromium-20.x (now in the cvs tree, hard masked) has selinux USE flag.
You can compile it yourself with USE=selinux and experiment with it, if
you want.

Feedback is welcome as always. :)
Attachments: signature.asc (0.20 KB)


phajdan.jr at gentoo

Apr 17, 2012, 6:26 AM

Post #5 of 7 (713 views)
Permalink
Re: www-client/chromium SELinux sandbox [In reply to]

On 4/12/12 7:09 AM, "Paweł Hajdan, Jr." wrote:
> On 4/10/12 10:10 PM, "Paweł Hajdan, Jr." wrote:
>> Chromium can be compiled to be SELinux-aware, and it forks itself (and
>> doesn't call exec - so that the underlying files can be updated in-place
>> without disrupting running browsers; this is because Chromium has
>> multi-process architecture and browser<->renderer IPC protocol changes
>> between versions).
>
> chromium-20.x (now in the cvs tree, hard masked) has selinux USE flag.
> You can compile it yourself with USE=selinux and experiment with it, if
> you want.

What are next steps here? Previous e-mails in this thread contain
suggested policy, and now chromium version with selinux support is in
tree (hard masked).

On #gentoo-hardened I received comments about unconfined_t usage in the
policy, but I'd really like to keep the main browser process unconfined
(see also <http://danwalsh.livejournal.com/15700.html>, and I don't want
to create as complicated policy for chromium like the reference mozilla
policy).

Should I file a bug and attach the policy there?
Attachments: signature.asc (0.20 KB)


swift at gentoo

Apr 17, 2012, 11:25 AM

Post #6 of 7 (709 views)
Permalink
Re: www-client/chromium SELinux sandbox [In reply to]

On Tue, Apr 17, 2012 at 03:26:42PM +0200, "Paweł Hajdan, Jr." wrote:
> What are next steps here? Previous e-mails in this thread contain
> suggested policy, and now chromium version with selinux support is in
> tree (hard masked).

As said on IRC (and per your suggestion), yes, a bugreport would do nicely
here (mailing to inform others that might be watching ;)

> On #gentoo-hardened I received comments about unconfined_t usage in the
> policy, but I'd really like to keep the main browser process unconfined
> (see also <http://danwalsh.livejournal.com/15700.html>, and I don't want
> to create as complicated policy for chromium like the reference mozilla
> policy).

I don't like dynamic transitions, let alone from unconfined. It's way more
"proper" to use a real application domain (even though that domain can still
be marked as unconfined for policies that support unconfined) and support
transitions (like is done with mozilla and mozilla_plugin_t).

But I don't think it'll be hard to develop a chrome module. I might do it
just to make better documentation on how to develop modules yourself.

Wkr,
Sven Vermeulen


phajdan.jr at gentoo

May 10, 2012, 1:19 AM

Post #7 of 7 (683 views)
Permalink
Re: www-client/chromium SELinux sandbox [In reply to]

On 4/17/12 8:25 PM, Sven Vermeulen wrote:
> On Tue, Apr 17, 2012 at 03:26:42PM +0200, "Paweł Hajdan, Jr." wrote:
>> What are next steps here? Previous e-mails in this thread contain
>> suggested policy, and now chromium version with selinux support is in
>> tree (hard masked).
>
> As said on IRC (and per your suggestion), yes, a bugreport would do nicely
> here (mailing to inform others that might be watching ;)

I filed <https://bugs.gentoo.org/show_bug.cgi?id=412637>
Attachments: signature.asc (0.20 KB)

Gentoo hardened RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.