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