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

Matt Thode mthode at mthode.org
Tue Sep 27 08:17:47 CDT 2011

On Sep 27, 2011, at 7:59 AM, Daniel J Walsh wrote:

> Hash: SHA1
> 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.
>>> -- Chris PeBenito Tresys Technology, LLC www.tresys.com |
>>> oss.tresys.com _______________________________________________ 
>>> refpolicy mailing list refpolicy at oss.tresys.com 
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>> 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.
>> -- Matthew Thode
> What about boolean settings, what about policy modifications?
> 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.
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> iEYEARECAAYFAk6ByKsACgkQrlYvE4MpobNwVgCfUk3gn+fEKp/4MGcuUxsUp51m
> /MsAnAh57u/56aguL7Ex688jWRy73o1f
> =nfDx

It is true that puppet would need special permissions to modify bools, can this be
done on policy installation?
I am trying to find a way so that puppet does not need to manage selinux
directly, but through package managers instead.

-- Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110927/c40c4a49/attachment.bin 

More information about the refpolicy mailing list