From: Craig.Grube@cobham.com (Grube, Craig)
Date: Thu, 27 Aug 2009 10:56:44 -0400
Subject: [refpolicy] puppet.patch
In-Reply-To: <4A968713.7020104@redhat.com>
References: <5ABE30CE099A524CBF95C715D37BCACC020A0190@nemo.columbia.ads.sparta.com>,
	<4A968713.7020104@redhat.com>
Message-ID: <586DC749-1CF9-48B1-BB19-50742EDB6270@mimectl>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

My overall goal was to get Puppet and SELinux 'playing nice' together.  By that I mean being able to constrain Puppet with SELinux and still have Puppet be functional for typical use, and being able to manage the configuration of SELinux clients with Puppet.  I haven't done much work beyond what is already in Puppet on the second front (managing SELinux clients).  The patch contains my work on the first front (constraining Puppet).

Constraining the Puppet server was relatively easy as it is a fairly simple network service; it needs to read its config, manage state, and communicate with networked clients.  

Given the amount of access required by the client for even basic routine usage (add/remove packages, manage arbitrary files, start/stop services) the obvious choices were to run unconstrained or attempt to build a policy that provides a broad level of access but still constrains the client.   I was also specifically interested in having SELinux related Puppet functionality working properly; specifically managing file labels, loading / unloading policy module, setting booleans, etc. and ended up trying to develop a policy that would constrain the Puppet client.

The current policy lets the client do several arguably scary things, specifically: manage all file types, load / unload SELinux policy, get / set SELinux booleans, execute arbitrary binaries, execute system shells (bash).

-c




From: Daniel J Walsh
Sent: Thu 8/27/2009 9:16 AM
To: Grube, Craig
Cc: refpolicy at oss1.tresys.com
Subject: Re: [refpolicy] puppet.patch

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/4a412067/attachment.html