From: dwalsh@redhat.com (Daniel J Walsh) Date: Tue, 27 Sep 2011 10:58:45 -0400 Subject: [refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t In-Reply-To: <4E81CFD6.80203@tresys.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> <4E81CFD6.80203@tresys.com> Message-ID: <4E81E4A5.3040500@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6B5KUACgkQrlYvE4MpobMDLgCfWJv4vdN8wbT/9lzahnhsLdbK /14An2JvagdqMSdu+LdLiiIxKeFNnlKn =m3j4 -----END PGP SIGNATURE-----