From: russell@coker.com.au (Russell Coker)
Date: Sun, 17 Sep 2017 15:16:30 +1000
Subject: [refpolicy] Chrome patch for discussion
In-Reply-To: <20170917041812.GA29152@meriadoc.perfinion.com>
References: <20170917032811.b2eyftg5j2wois4n@athena.coker.com.au>
	<20170917041812.GA29152@meriadoc.perfinion.com>
Message-ID: <48575314.ulVpVAA9Qd@russell.coker.com.au>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Sunday, 17 September 2017 12:18:12 PM AEST Jason Zaman wrote:
> We've had a chromium_t in gentoo for quite a while
> 
> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/co
> ntrib/chromium.te
> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/c
> ontrib/chromium.if
> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/c
> ontrib/chromium.fc
> 
> I kinda like firefox and chromium separate cuz chrome has a bunch of
> booleans for chromecast and fido u2f and stuff so then less perms can be
> given to FF.
> 
> Also other stuff is that FF can work without execmem if you build with
> JIT disabled but chrome wont.

Those are good reasons for separating the domains.

> If we're separating the domains then we can just use the gentoo one
> instead of having to re-write. I can send it upstream if its good.
> Any comments on it?

Your policy is more comprehensive than mine.

How does that chromium_renderer_t work?  Is that a standard chrome feature or 
something special you did?  It would probably be best to have a comment in the 
policy about this.

It seems that the only difference between chromium_xdg_config_t and 
chromium_xdg_cache_t is that the latter can't be read by chromium_renderer_t.  
Is that sufficient reason to have an extra type?

Apart from that it appears ok to me.  NB I haven't run it, I've just inspected 
it.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/