From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 27 Sep 2011 11:57:39 -0400 Subject: [refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t In-Reply-To: <4E81E4A5.3040500@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> <4E81CFD6.80203@tresys.com> <4E81E4A5.3040500@redhat.com> Message-ID: <4E81F273.1090903@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 09/27/11 10:58, 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: >>> 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. So what needs to be decided is where to draw the line. I think we should look to something reasonable inside the base functionality. The problem is that puppet's base support is already pretty broad. I think the minimum we want is: * edit etc_t files * tunable: edit all config files some other reasonable ones are: * tunable: start & stop services * tunable: toggle SELinux Booleans * tunable: manage users & groups * tunable: manage packages (eg run yum/rpm, etc.) -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com