From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Mon, 9 Jan 2012 21:52:20 +0100
Subject: [refpolicy] Contribute chrome (sandbox) policy from Fedora to
Refpolicy.
In-Reply-To: <4F072EA4.2050209@redhat.com>
References: <4F072EA4.2050209@redhat.com>
Message-ID: <20120109205220.GE3416@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com
On Fri, Jan 06, 2012 at 12:25:56PM -0500, Daniel J Walsh wrote:
> Please review and Ack.
[...]
> +########################################
> +##
> +## Role access for chrome sandbox
> +##
> +##
> +##
> +## Role allowed access
> +##
> +##
> +##
> +##
> +## User domain for the role
> +##
> +##
> +#
> +interface(`chrome_role_notrans',`
Since the module will be called chrome, I can imagine it wouldn't take long
before chrome is put in its own domain. For this reason, I'd try to keep the
_sandbox suffix wherever possible.
Perhaps chrome_role_notrans_sandbox ?
> +########################################
> +##
> +## Role access for chrome sandbox
> +##
> +##
> +##
> +## Role allowed access
> +##
> +##
> +##
> +##
> +## User domain for the role
> +##
> +##
> +#
> +interface(`chrome_role',`
chrome_role_sandbox
> +########################################
> +##
> +## Dontaudit read/write to a chrome_sandbox leaks
> +##
> +##
> +##
> +## Domain to not audit.
> +##
> +##
> +#
> + gen_require(`
> + type chrome_sandbox_t;
> + ')
> +
> + dontaudit $1 chrome_sandbox_t:unix_stream_socket { read write };
> +')
I'm missing the interface call here.
chrome_dontaudit_rw_unix_stream_sockets_sandbox?
> +ubac_constrained(chrome_sandbox_tmpfs_t)
I'm not certain, but if you mark this resource as ubac-constrained, doesn't
chrome_sandbox_t need to be marked as such as well? Same for
chrome_sandbox_nacl_t?
Wkr,
Sven Vermeulen