[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[cpebenito@tresys.com (Christopher J. PeBenito)]

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