From: Craig.Grube@cobham.com (Grube, Craig)
Date: Thu, 27 Aug 2009 09:24:00 -0400
Subject: [refpolicy] puppet.patch
In-Reply-To: <20090827103107.GA2495@notebook3.grift.internal>
References: <5ABE30CE099A524CBF95C715D37BCACC020A0190@nemo.columbia.ads.sparta.com>,
	<20090827103107.GA2495@notebook3.grift.internal>
Message-ID: <0BE19D42-8DB2-4D0A-993F-86B55A61C2E8@mimectl>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

I have no issues with most of the comments and will include those in an updated patch.  I do have a couple of questions about several comments.  

> It looks like you've designed this policy on RHEL5 or some older implementation of selinux-policy.

Correct.  Most of the work was done in Fedora Core 11.

> +interface(`puppet_run_semanage',`
> should be:
> is not allowed
> # END
> +interface(`puppet_run_setsebool',`
> should be:
> is not allowed
> # END

The version of Puppet I'm working with relies on semanage and get/setsebool to manage client's SELinux configuration (i.e. load/unload policy modules, set booleans, etc.) Is the issue with the naming convention or is it preferred that Puppet not be able to manage client's SELinux configuration at all, or that the interfaces be moved into a policy module outside of the reference policy?

> +interface(`puppet_init_scripts_domtrans',`
> should be:
> not allowed
> # END

Same question as the previous one, is the issue with the naming convention or with the ability of Puppet to cycle system services? 

Puppet restarts system services after updating configuration files, installing new packages, etc. In the absence of the interface Puppet is either unable to cycle system services or cycled services run in the puppet domain instead of the domain intended for the particular service.  Not being able to cycle services would make Puppet not so usefu   

I had the interface contents in puppet.te, but moved them into an interface when I needed to pull in the init_script_file_type attribute.  The move was based on my understanding that the use of interfaces and gen_require is preferred over using require blocks.  

> allow puppet_t self:capability { sys_admin fowner fsetid setuid setgid sys_rawio dac_override sys_nice sys_ptrace sys_tty_config };
> Comment:
> is that really required?

Probably not all are required.  Some were required to get the service to run, all appeared in the audit logs but are probably not all necessary for Puppet to function properly.  

-- 
Craig Grube 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/ac82db1e/attachment-0001.html