[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t
Christopher J. PeBenito
cpebenito at tresys.com
Tue Sep 27 10:57:39 CDT 2011
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.)
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
More information about the refpolicy