From: Craig.Grube@cobham.com (Craig Grube)
Date: Tue, 8 Sep 2009 19:23:57 -0400
Subject: [refpolicy] puppet.patch - updated
In-Reply-To: <20090908102804.GA10519@notebook3.grift.internal>
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>
	<20090908102804.GA10519@notebook3.grift.internal>
Message-ID: <0A2D58E9-8857-4B82-A2F0-A18E1B9FEEA2@cobham.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com


On Sep 8, 2009, at 6:28 AM, Dominick Grift wrote:
> 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?

They need to manage puppet_var_lib_t as both the client and server add/ 
remove files/directories in /var/lib/puppet, so they need to be able  
to manage files and directories of that type.  /var/log/puppet and / 
var/run/puppet are created by the rpm and puppet/puppetmaster only add/ 
remove files in these directories.  I trimmed the directory  
permissions back to rw_dir_perms, setattr_dir_perms and left the file  
permissions alone.  I didn't encounter issues during testing with  
these permissions.

>> 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.`:


I added domain_interactive_fd, the other modules already had  
domain_use_interactive_fds, which cleared up the issue with  
redirection to /dev/null.

I also tracked down most of the remaining audit errors and made  
additions.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: puppet.te
Type: application/octet-stream
Size: 6878 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090908/81744b5c/attachment.obj 
-------------- next part --------------