FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 04-10-2012, 11:11 AM
"Paweł Hajdan, Jr."
 
Default 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?
policy_module(chromium-browser,1.0.0)

gen_require(`
type tmp_t;
type tmpfs_t;
type unconfined_t;
type user_tmpfs_t;
type urandom_device_t;
type xdg_config_home_t;
role unconfined_r;
')

type chromium_renderer_t;
domain_base_type(chromium_renderer_t)
role unconfined_r types chromium_renderer_t;

allow unconfined_t chromium_renderer_trocess dyntransition;

allow chromium_renderer_t self:fifo_file { read write };
allow chromium_renderer_t selfrocess execmem;
allow chromium_renderer_t self:shm { create destroy read write unix_read unix_write };
allow chromium_renderer_t self:unix_dgram_socket { create read sendto };
allow chromium_renderer_t self:unix_stream_socket { create getattr read };

allow chromium_renderer_t tmp_t:dir { read getattr open };
allow chromium_renderer_t tmpfs_t:file { read write };
allow chromium_renderer_t user_tmpfs_t:file { read getattr append };

allow chromium_renderer_t unconfined_t:fd use;
allow chromium_renderer_t unconfined_t:unix_stream_socket { read write };

allow chromium_renderer_t urandom_device_t:chr_file { getattr open read };

allow chromium_renderer_t xdg_config_home_t:file { getattr read };

miscfiles_read_localization(chromium_renderer_t);
miscfiles_read_fonts(chromium_renderer_t);
 
Old 04-10-2012, 05:46 PM
Sven Vermeulen
 
Default www-client/chromium SELinux sandbox

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
 
Old 04-10-2012, 08:10 PM
"Paweł Hajdan, Jr."
 
Default www-client/chromium SELinux sandbox

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=setc on&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.
policy_module(chromium-browser, 1.0.0)

gen_require(`
type unconfined_t;
type user_tmpfs_t;
role unconfined_r;
')

type chromium_renderer_t;
domain_base_type(chromium_renderer_t)
role unconfined_r types chromium_renderer_t;

dyntrans_pattern(unconfined_t, chromium_renderer_t);

allow chromium_renderer_t self:fifo_file rw_fifo_file_perms;
allow chromium_renderer_t selfrocess execmem;
allow chromium_renderer_t self:shm { create destroy read write unix_read unix_write };
allow chromium_renderer_t self:unix_dgram_socket { create read sendto };
allow chromium_renderer_t self:unix_stream_socket { create getattr read };

allow chromium_renderer_t unconfined_t:unix_stream_socket rw_stream_socket_perms;
allow chromium_renderer_t user_tmpfs_t:file { read getattr append };

dev_read_urand(chromium_renderer_t);
files_list_tmp(chromium_renderer_t);
fs_rw_tmpfs_files(chromium_renderer_t);
miscfiles_read_localization(chromium_renderer_t);
miscfiles_read_fonts(chromium_renderer_t);
unconfined_use_fds(chromium_renderer_t);
xdg_read_generic_config_home_files(chromium_render er_t);
 
Old 04-12-2012, 05:09 AM
"Paweł Hajdan, Jr."
 
Default www-client/chromium SELinux sandbox

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.
 
Old 04-17-2012, 01:26 PM
"Paweł Hajdan, Jr."
 
Default www-client/chromium SELinux sandbox

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?
 
Old 04-17-2012, 06:25 PM
Sven Vermeulen
 
Default www-client/chromium SELinux sandbox

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
 
Old 05-10-2012, 08:19 AM
"Paweł Hajdan, Jr."
 
Default www-client/chromium SELinux sandbox

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>
 

Thread Tools




All times are GMT. The time now is 09:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org