From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 11 Nov 2011 19:37:51 +0100
Subject: [refpolicy] [PATCH 1/3] Introduce vde domain
In-Reply-To: <4EB94452.9010009@tresys.com>
References: <20111023140743.GA14481@siphos.be>
	<20111023140825.GB14481@siphos.be> <4EB94452.9010009@tresys.com>
Message-ID: <20111111183751.GA8548@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, Nov 08, 2011 at 10:01:38AM -0500, Christopher J. PeBenito wrote:
> > +	tunable_policy(`gentoo_try_dontaudit',`
> > +		dontaudit $1 vde_var_run_t:sock_file { setattr };
> > +	')
> 
> Remember to remove these testing rules.  Its also unnecessary to have the braces for single permissions.

Yeah, sorry about that.

> > +allow vde_t self:process { signal_perms getcap setcap };
> > +allow vde_t self:capability { chown net_admin dac_override fowner fsetid };
> > +allow vde_t self:unix_stream_socket {  create_stream_socket_perms connectto };
> > +allow vde_t self:unix_dgram_socket create_socket_perms;
> > +allow vde_t vde_conf_t:dir list_dir_perms;
> > +allow vde_t vde_tmp_t:sock_file manage_sock_file_perms;
> 
> Please move these down with the other rules.

You mean keep the "allow" statements with the general patterns? Like so?

  allow vde_t self:process { signal_perms getcap setcap };
  allow vde_t self:capability { chown net_admin dac_override fowner fsetid };
  allow vde_t self:unix_stream_socket {  create_stream_socket_perms connectto };
  allow vde_t self:unix_dgram_socket create_socket_perms;
  
  manage_dirs_pattern(vde_t, vde_var_run_t, vde_var_run_t)
  manage_files_pattern(vde_t, vde_var_run_t, vde_var_run_t)
  manage_sock_files_pattern(vde_t, vde_var_run_t, vde_var_run_t)
  files_pid_filetrans(vde_t, vde_var_run_t, { dir file sock_file unix_dgram_socket })
  
  allow vde_t vde_tmp_t:sock_file manage_sock_file_perms;
  
  files_tmp_filetrans(vde_t, vde_tmp_t, sock_file)
  

Is it okay to have a whitespace between allow blocks and other (general
pattern) blocks?

> I'm not clear why there is a need for vde_conf_t.  It appears that it is only
> ever read, so it seems that etc_t would be fine.

True. I had defined it to allow for third party applications to manage it,
but it seems that those that I expect to manage them also have etc_t write
privileges already (like puppet).

I'll remove it from the renewed submission.

Wkr,
	Sven Vermeulen