From: Craig.Grube@cobham.com (Craig Grube)
Date: Mon, 7 Sep 2009 14:39:08 -0400
Subject: [refpolicy] puppet.patch - updated
In-Reply-To: <20090906162341.GA4976@notebook3.grift.internal>
References: <4AA106F0.9000603@cobham.com>
	<20090905093847.GB29896@notebook3.grift.internal>
	<4AA3E02F.7040500@cobham.com>
	<20090906162341.GA4976@notebook3.grift.internal>
Message-ID: <832FE86D-3F2E-446E-BA8F-BF2D200FB473@cobham.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Sep 6, 2009, at 12:23 PM, Dominick Grift wrote:
> On Sun, Sep 06, 2009 at 12:15:43PM -0400, Craig Grube wrote:
>> 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.
>
> So who owns these files? puppet or puppetmaster? Do they both create  
> them (both own them?)

The short answer is they both create and own these files.

The long answer the client and server typically both use the same  
paths.  It looks as though in Fedora, Gentoo and SUSE pid files are  
in /var/run/puppet/ (based on distribution specific configuration  
files in the puppet source repository).  The same for /var/log/ 
puppet.  The client and server both use /var/lib/puppet for storing  
state information. Puppetmaster stores CA related files, client  
certificates, parsed client configurations. Puppet stores  
certificates, last retrieved configuration, and backups of changed  
files.

For the distributions I've looked at, ubuntu and fedora, the client  
package is a dependency of the server package, which was part of my  
reasoning for associating shared areas of the file system with the  
puppet client and then provide the puppetmaster with access.

>> 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.
> ok if required i guessno harm in adding it. however is there no  
> interface available that you can use?
> check the domain interface file for that

I did not notice these before, but does is seem reasonable to use  
domain_interactive_fd(puppet_t) in the puppet policy and add  
domain_use_interactive_fds in the modules controlling the before  
mentioned types?

Craig