From: dwalsh@redhat.com (Daniel J Walsh)
Date: Mon, 26 Sep 2011 11:41:10 -0400
Subject: [refpolicy] [PATCH 1/1] Mount output should be writeable to
	puppet_tmp_t
In-Reply-To: <1317049868.18323.4.camel@x220.mydomain.internal>
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>
Message-ID: <4E809D16.4040109@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
>>> 
>>> Wkr, Sven Vermeulen 
>>> _______________________________________________ refpolicy
>>> mailing list refpolicy at oss.tresys.com 
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>> 
>> 
>> 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.
> 
> 
>> _______________________________________________ refpolicy mailing
>> list refpolicy at oss.tresys.com 
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com 
> http://oss.tresys.com/mailman/listinfo/refpolicy


We are in violent agreement.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6AnRYACgkQrlYvE4MpobMpSgCgqaf3wMdU0417M/+Zz07iBShN
w1QAoJljNjlJKLTBm+BNU6V4DuGktUgM
=jJRP
-----END PGP SIGNATURE-----