From: mthode@mthode.org (Matt Thode) Date: Tue, 27 Sep 2011 08:17:47 -0500 Subject: [refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t In-Reply-To: <4E81C8AC.60308@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> <4E80C4F7.2030903@tresys.com> <4E81C8AC.60308@redhat.com> Message-ID: <31F89FEE-9708-47CA-8CEA-ED515720E910@mthode.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sep 27, 2011, at 7:59 AM, Daniel J Walsh wrote: > -----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----- It is true that puppet would need special permissions to modify bools, can this be done on policy installation? I am trying to find a way so that puppet does not need to manage selinux directly, but through package managers instead. -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 881 bytes Desc: This is a digitally signed message part Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110927/c40c4a49/attachment.bin