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

Dominick Grift dominick.grift at gmail.com
Mon Sep 26 10:11:08 CDT 2011


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.
> > 
> > Wkr, Sven Vermeulen 
> > _______________________________________________ refpolicy mailing
> > list refpolicy at oss.tresys.com 
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 
> 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.


> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy




More information about the refpolicy mailing list