From: dwalsh@redhat.com (Daniel J Walsh) Date: Tue, 27 Sep 2011 08:59:24 -0400 Subject: [refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t In-Reply-To: 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> <4E80C4F7.2030903@tresys.com> Message-ID: <4E81C8AC.60308@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/26/2011 03:36 PM, Matt Thode wrote: > On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito wrote: >> 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 _______________________________________________ >> refpolicy mailing list refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy > > > Well, the way puppet should manage anything selinux related should > be though packages I think. For instance, I have puppet set up to > install selinux-nginx on gentoo. Then if I place a file via puppet > it gets relabeled automatically via the file context. > > -- Matthew Thode What about boolean settings, what about policy modifications? The main point is admins are going to need to administrate their systems with puppet, and they are going to do what needs to get done. Usually this is going to move towards and unconfined domain, especially for general purpose OS. One problem with adding lots of transitions and allows to a puppet domain, is that it makes making a truly confined an controlled puppet_t very difficult. For example if all I want to do is allow puppet_t to manage my apache content, and we add lots of transitions to things line mount_t we can not get a limited prived puppet_t. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ByKsACgkQrlYvE4MpobNwVgCfUk3gn+fEKp/4MGcuUxsUp51m /MsAnAh57u/56aguL7Ex688jWRy73o1f =nfDx -----END PGP SIGNATURE-----