[refpolicy] puppet.patch - updated

[domg472@gmail.com (Dominick Grift)]

On Tue, Sep 08, 2009 at 07:23:57PM -0400, Craig Grube wrote:

looks good to me, One thing that may or or may not be improved is that some of the called interfaces in puppet.te may be optional_policy. To figure that out requires a bit of investigation. You could look up the interface calls in other established refpolicy modules and see whether they are optional there. If they are: wrap them in a optional_policy block and move the blocks below where the other optional policy is (in alphabetical order)

But from my point of view the policy looks rather nice now.

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


>
>
>
>
>
>
>
>

> _______________________________________________
> 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/20090909/355d904f/attachment.bin