From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Contribute chrome (sandbox) policy from Fedora to Refpolicy.
Date: Mon, 9 Jan 2012 21:52:20 +0100 [thread overview]
Message-ID: <20120109205220.GE3416@siphos.be> (raw)
In-Reply-To: <4F072EA4.2050209@redhat.com>
On Fri, Jan 06, 2012 at 12:25:56PM -0500, Daniel J Walsh wrote:
> Please review and Ack.
[...]
> +########################################
> +## <summary>
> +## Role access for chrome sandbox
> +## </summary>
> +## <param name="role">
> +## <summary>
> +## Role allowed access
> +## </summary>
> +## </param>
> +## <param name="domain">
> +## <summary>
> +## User domain for the role
> +## </summary>
> +## </param>
> +#
> +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 ?
> +########################################
> +## <summary>
> +## Role access for chrome sandbox
> +## </summary>
> +## <param name="role">
> +## <summary>
> +## Role allowed access
> +## </summary>
> +## </param>
> +## <param name="domain">
> +## <summary>
> +## User domain for the role
> +## </summary>
> +## </param>
> +#
> +interface(`chrome_role',`
chrome_role_sandbox
> +########################################
> +## <summary>
> +## Dontaudit read/write to a chrome_sandbox leaks
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain to not audit.
> +## </summary>
> +## </param>
> +#
> + 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
prev parent reply other threads:[~2012-01-09 20:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 17:25 [refpolicy] Contribute chrome (sandbox) policy from Fedora to Refpolicy Daniel J Walsh
2012-01-09 20:52 ` Sven Vermeulen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120109205220.GE3416@siphos.be \
--to=sven.vermeulen@siphos.be \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.