From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Contribute ctdbd policy from Fedora to Refpolicy
Date: Mon, 9 Jan 2012 22:46:04 +0100 [thread overview]
Message-ID: <20120109214603.GK3416@siphos.be> (raw)
In-Reply-To: <4F0B5A9E.10308@redhat.com>
On Mon, Jan 09, 2012 at 04:22:38PM -0500, Daniel J Walsh wrote:
> > Same here like with boinc, is there a possibility to have some
> > segregation between the "regular" ctdbd_var_lib_t and the files
> > ctdbd_t wants to execute?
>
> Maybe if these have a constant name, but we have to ask Miroslav.
> Maybe we could use file_name_trans rules, but I still think we end up
> with a type that has to be written and executed by the same domain.
It's a bit odd that it's the "generic" _var_lib_t domain for this purpose.
It gives users a different impression (I don't imagine that any *_var_lib_t
is executed by its "parent" domain).
$ sesearch -c file -p write -A | grep execute | grep var_lib
allow xserver_t xkb_var_lib_t : file { write ... execute execute_no_trans } ;
That's the only one on my system where a domain has both write and execute
rights to a _var_lib_t type. When I'm aware of a domain writing and executing
files (because its "flexible" that way) I always hope that this results in a
separate domain (like with boic) or that it isn't for a wide type.
Of course, there are plenty of examples out there where this doesn't hold up
(like logrotate_t having write/execute rights for logrotate_tmp_t) so I'm
not /against/ these policies (boinc and ctdbd), just careful.
Wkr,
Sven Vermeulen
prev parent reply other threads:[~2012-01-09 21:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 17:28 [refpolicy] Contribute ctdbd policy from Fedora to Refpolicy Daniel J Walsh
2012-01-09 21:08 ` Sven Vermeulen
2012-01-09 21:22 ` Daniel J Walsh
2012-01-09 21:46 ` 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=20120109214603.GK3416@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.