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

Dominick Grift dominick.grift at gmail.com
Tue Sep 27 11:37:06 CDT 2011


On Tue, 2011-09-27 at 10:58 -0400, 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:
> >> 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.

that was maybe the case in the past. nowadays one can just disable a
module like puppet and clone it from source, then modify and load the
clone (at least if all goes well)

> 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.
> 
I think the emphasis is often much on restriction rather than integrity.
No policy is ever perfect but should that keep us from trying?

instead of looking what it can or should do one can also look at what it
cant or should not do.

sure puppet might be used for many things but there are also things
where it is not used for, and i think the focus could be on that more.

Yes it would be a very permissive domain ( but like SwifT said we could
later make functionality tunable ) but that is the nature of this
program.

I guess the question comes down to this;

1. Do we expect people that use puppet for the more exotic
configurations and want to run selinux policy "strict" to modify puppet
policy themselves.

2. Or do we expect people that want a puppet policy tailored to their
specific requirements and want to run selinux policy "strict" to modify
policy themselves.

I think i would go for "2." since no policy is ever perfect.

Besides the policy in fedora is typically general purpose in many cases,
so supporting a general purpose puppet domain would fit that profile.

It is easy to say "the buck stops here" but we the community as a whole
can create a better policy than any single entity alone i believe. So
why not take advantage of that: yes it can do a lot of things that not
everyone may use, but on the brighter side; it also can't do a lot of
things that it should not do. Isnt that what its about in the end?
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110927/9111cc81/attachment.bin 


More information about the refpolicy mailing list