Re: [gentoo-hardened] www-client/chromium SELinux sandbox

[Sven Vermeulen]

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