All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.