From: domg472@gmail.com (Dominick Grift)
Date: Tue, 8 Sep 2009 12:28:07 +0200
Subject: [refpolicy] puppet.patch - updated
In-Reply-To: <832FE86D-3F2E-446E-BA8F-BF2D200FB473@cobham.com>
References: <4AA106F0.9000603@cobham.com>
	<20090905093847.GB29896@notebook3.grift.internal>
	<4AA3E02F.7040500@cobham.com>
	<20090906162341.GA4976@notebook3.grift.internal>
	<832FE86D-3F2E-446E-BA8F-BF2D200FB473@cobham.com>
Message-ID: <20090908102804.GA10519@notebook3.grift.internal>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, Sep 07, 2009 at 02:39:08PM -0400, Craig Grube wrote:
> 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.

I see. But the permissions in those location can probably still be tightened. Do they really need to create dirs? or are those dirs already installed by the rpm package?
> 
> >> 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?

Yes my bet is that using that interface is the better solution and if required should be called in the modules that needs it.`:
> 
> Craig
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090908/8f5d387f/attachment.bin