From: dwalsh@redhat.com (Daniel J Walsh)
Date: Thu, 27 Aug 2009 10:54:56 -0400
Subject: [refpolicy] puppet.patch
In-Reply-To: <1251381799.8357.52.camel@gorn.columbia.tresys.com>
References: <5ABE30CE099A524CBF95C715D37BCACC020A0190@nemo.columbia.ads.sparta.com>	
	<4A968713.7020104@redhat.com>
	<1251381799.8357.52.camel@gorn.columbia.tresys.com>
Message-ID: <4A969E40.7050204@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/27/2009 10:03 AM, Christopher J. PeBenito wrote:
> On Thu, 2009-08-27 at 09:16 -0400, Daniel J Walsh wrote:
>> On 08/26/2009 07:45 PM, Grube, Craig wrote:
>>>
>>> The attached patch contains policy for Puppet, a configuration
>>> management tool.  It contains two new services, for the client and
>>> server components of Puppet, and adds a new network port type for
>>> Puppet's use.
>>>
>>> If any changes are desired please let me know and I will provide
>>> updated patches as my schedule permits.
>>
>> What is your security goals for puppet?  Are you going to allow it to
>> write to anywhere on the system?  Seems that a configuration system
>> like puppet needs to have full access unless a user can specify his
>> security goals.
> 
> I don't agree with full access being needed.  Its a configuration
> management system, so it seems that a reasonable starting policy would
> be able to manage files in /etc, in addition to doing things like run
> useradd, semanage, mount, ifconfig, etc.
> 

Also needs to be able to install rpm, but I have seen puppet used to move files all over the place, such as apache content.
I am not sure you are getting a great increase in security if I have all of these capabilities.

I guess we could write policy that defaults puppet to unconfined_t and then have people choose to run a tighter policy around what puppet is actually doing on their machine.