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

[dwalsh@redhat.com (Daniel J Walsh)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/27/2011 09:29 AM, Christopher J. PeBenito wrote:
> 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.
> 
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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6B5KUACgkQrlYvE4MpobMDLgCfWJv4vdN8wbT/9lzahnhsLdbK
/14An2JvagdqMSdu+LdLiiIxKeFNnlKn
=m3j4
-----END PGP SIGNATURE-----