From: Craig.Grube@cobham.com (Craig Grube)
Date: Sun, 06 Sep 2009 12:15:43 -0400
Subject: [refpolicy] puppet.patch - updated
In-Reply-To: <20090905093847.GB29896@notebook3.grift.internal>
References: <4AA106F0.9000603@cobham.com>
	<20090905093847.GB29896@notebook3.grift.internal>
Message-ID: <4AA3E02F.7040500@cobham.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

I tested the policy and attached a modified version that mostly works. 
The main issue I encountered was puppetmaster's level of access to types 
puppet_var_run_t, puppet_var_lib_t, puppet_tmp_t were insufficient.  I 
replicated puppet's accesses for puppetmaster and it works.

There are still some AVCs being generated including these:

For puppetmaster:
	- Wants write, read, setattr to puppet_log_t files.

For puppet:
	- Appears to redirect output (not sure at this point if stderr or 
stdout) from system utilities to /dev/null which results in AVCs like this:

type=AVC msg=audit(1252178670.560:136): avc:  denied  { use } for 
pid=1694 comm="modprobe" path="/dev/null" dev=tmpfs ino=400 
scontext=system_u:system_r:insmod_t tcontext=system_u:system_r:puppet_t 
tclass=fd

I am seening these for insmod_t, ldconfig_t, initrc_t, and rpm_script_t. 
  I had a 'dontaudit domain puppet_t:fd use'  to squash these AVCs, 
which does not appear from my testing to negatively effect puppet.
	
Craig

Dominick Grift wrote:
> On Fri, Sep 04, 2009 at 08:24:16AM -0400, Craig Grube wrote:
> 
> I already made some modification to my own take of the policy. More modification are probably to follow.
> You can find my current (up-to-date) policy for puppet here:
> 
> http://82.197.205.60/~dgrift/stuff/modules/puppet/
> 
> Again, This policy is untested. there are likely errors left.
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: puppet.te
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20090906/fea51656/attachment.pl