From: dwalsh@redhat.com (Daniel J Walsh) Date: Tue, 27 Sep 2011 14:06:42 -0400 Subject: [refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t In-Reply-To: <1317141426.2861.55.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> <4E809D16.4040109@redhat.com> <4E80C4F7.2030903@tresys.com> <4E81C8AC.60308@redhat.com> <4E81CFD6.80203@tresys.com> <4E81E4A5.3040500@redhat.com> <1317141426.2861.55.camel@x220.mydomain.internal> Message-ID: <4E8210B2.9090001@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/27/2011 12:37 PM, Dominick Grift wrote: > On Tue, 2011-09-27 at 10:58 -0400, Daniel J Walsh wrote: >> On 09/27/2011 09:29 AM, Christopher J. PeBenito wrote: >>> On 09/27/11 08:59, Daniel J Walsh wrote: >>>> 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. >>>>>> >>>>> 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. >>> >>> I assume either it is installed correctly with setfscreatecon() >>> or you run restorecon on it? >>> >>>> What about boolean settings, what about policy >>>> modifications? >>> >>> I'd be fine with puppet directly altering booleans via >>> libselinux calls. Policy modifications should go through >>> semodule/semanage. >>> >>>> 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. >>> >>> I don't understand how your example demonstrates a problem >>> with this approach. To me, it seems like we agree. People who >>> want a nice confined system aren't going to have unconfined >>> anyway, so the non-unconfined case need to have a reasonable >>> use case. For the more general case, people will have the >>> unconfined module, and puppet will be unconfined. >>> >> I guess I am arguing not to add functionality to much >> functionality to puppet, so we have a tightly secured puppet, and >> then allow people who care about confining it to extend it. >> Otherwise we will end up with a puppet policy that is somewhere >> in the middle, which does neither group any good. >> >> For example, if you allow puppet to transition to useradd_t, >> mount_t, and the ability to write to security_t, then I can not >> write a more confined policy for my puppet from the reference >> policy. > > that was maybe the case in the past. nowadays one can just disable > a module like puppet and clone it from source, then modify and load > the clone (at least if all goes well) > >> I guess I would opt for Minimal puppet_t enough to let the >> service run and listen on the puppet port. Maybe allow it to >> read system files. >> >> And an unconfined_domain(puppet_t), for those of us who have no >> idea what puppet will do. >> > I think the emphasis is often much on restriction rather than > integrity. No policy is ever perfect but should that keep us from > trying? > > instead of looking what it can or should do one can also look at > what it cant or should not do. > > sure puppet might be used for many things but there are also > things where it is not used for, and i think the focus could be on > that more. > > Yes it would be a very permissive domain ( but like SwifT said we > could later make functionality tunable ) but that is the nature of > this program. > > I guess the question comes down to this; > > 1. Do we expect people that use puppet for the more exotic > configurations and want to run selinux policy "strict" to modify > puppet policy themselves. > > 2. Or do we expect people that want a puppet policy tailored to > their specific requirements and want to run selinux policy "strict" > to modify policy themselves. > > I think i would go for "2." since no policy is ever perfect. > > Besides the policy in fedora is typically general purpose in many > cases, so supporting a general purpose puppet domain would fit that > profile. > > It is easy to say "the buck stops here" but we the community as a > whole can create a better policy than any single entity alone i > believe. So why not take advantage of that: yes it can do a lot of > things that not everyone may use, but on the brighter side; it also > can't do a lot of things that it should not do. Isnt that what its > about in the end? >> _______________________________________________ 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 Fine I was arguing what I thought Chris would want for his people who do full lock down. Allowing puppet common configuration issues is fine. You might need to allow puppet to change the labels if you are going to allow it to manipulate etc_t. relabelfrom puppet file types. Relabelto types that puppet is allowed to manage. Since puppet might first create its content in /run or /tmp. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6CELIACgkQrlYvE4MpobNbfACg1jJRTjfYfYMNh7/u+S6FwYAT cWwAmgMi4bkZhfhxOAdV48krEYHgYv0a =dKj7 -----END PGP SIGNATURE-----