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

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

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