From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 27 Sep 2011 09:29:58 -0400 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: <4E81CFD6.80203@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com