From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 26 Sep 2011 14:31:19 -0400
Subject: [refpolicy] [PATCH 1/1] Mount output should be writeable to
	puppet_tmp_t
In-Reply-To: <4E809D16.4040109@redhat.com>
References: <20110924135657.GA8045@siphos.be>
	<1316877524.9488.16.camel@x220.mydomain.internal>
	<1316877756.9488.19.camel@x220.mydomain.internal>
	<4E807A5B.3050602@redhat.com> <20110926142242.GA14599@siphos.be>
	<4E8093E6.8060605@redhat.com>
	<1317049868.18323.4.camel@x220.mydomain.internal>
	<4E809D16.4040109@redhat.com>
Message-ID: <4E80C4F7.2030903@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 09/26/11 11:41, Daniel J Walsh wrote:
> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh
>>>> wrote:
>>>>> We usually go from permissive to unconfined when we try to
>>>>> spin off to beta.  But making puppet confined is probably a
>>>>> waste of time anyways, since it pretty much needs to be able
>>>>> to do anything.
>>>>
>>>> I disagree. Even powerful domains should be confined. I'd 
>>>> personally like to go even further and make sure that the
>>>> policy is flexible enough to deal with limited use - for
>>>> instance, if I use puppet only for ensuring mounts, then it
>>>> should not be able to reload selinux policies (or transition to
>>>> domains that can). Although we are definitely not there yet, I
>>>> believe that we should at least first see how confining puppet
>>>> goes.
>>>>
>>>> Once a more complete policy is found, we can see if this can
>>>> be segregated nicely.
>>>>
>>>> Furthermore, the puppet policy itself has most of its "power" 
>>>> through domain transitions, not through elevated privileges on
>>>> the puppet_t domain itself. Although remote command execution
>>>> is still exploitable through this, making puppet SELinux-aware
>>>> might help to reduce attacks there as well.
>>>>
>>> My point being that it is very difficult to make a policy for
>>> the masses that will work with a domain that can place files
>>> anywhere and even needs to be able to turn on and off SELinux.
>>> Setting booleans, file_context, policy modules, are all things
>>> that puppet does within the Fedora infrastructure.
> 
>> We arent (at least i am not) saying these domain cannot be
>> unconfined eventually. I am just saying it should be optional.
> 
>> That means that during rawhide we make these unconfined domain, 
>> permissive domains and use the reports to perfect the policy for
>> any scenario. then when rawhide gets branched we make it unconfined
>> again so that "the masses?? get an unconfined puppet. But if one
>> decides to remove the unconfined domains , puppet will still work
>> (atleast better than currently) because we kept perfecting policy
>> during the rawhide.
> 
> We are in violent agreement.

I think we should take a best effort approach to situations like this.  Based on my (albeit limited) perspective of puppet usage, its for managing system config.  So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing.  I'm comfortable with the policy supporting this level of access.  Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com