On Fri, 2008-09-12 at 13:33 -0400, Stephen Smalley wrote:
That isn't what I meant. I said to put puppet in its domain so
that the
policy rules can define a type for files it creates in /tmp that are
different than the type used by any other process, and then we can allow
all service domains to read that new type created only by puppet w/o
exposing the temporary files of any other process to such access. See
the difference? What domain does puppet run in presently, initrc_t?
Ah, okay. Now I get it. I didn't realize/understand that putting it in
its own domain would provide a route to do that. Puppet runs in
initrc_t if started via /etc/init.d/puppet and in unconfined_t if run as
puppetd from the command line (which I frequently do for testing new
configs).
This step becomes unnecessary if we put puppet into its own domain
and
define a file type transition to a new type, say puppet_tmp_t when
creating files in /tmp, and then the puppet policy can say "allow domain
puppet_tmp_t:file { read write getattr append };"
Okay, I think it starting to make sense to me now.
Between your explanation and Dan's sample policy and explanation I think
I am starting to understand what is needed.
So, to clarify, if I create the new puppet domain definition and policy
correctly I theoretically won't even need to modify a line of Puppet
code itself? It seems I have some more learning to do :)
I think I am going to try this approach and see if I can come up with a
policy that will cover a domain transition and the required labeling.
The approach above will work for existing distributions but will
allow
the service domains to potentially open other files created by puppet
in /tmp as well (but not open arbitrary /tmp files created by other
processes). Then in newer distributions where the new open permission
is enabled in policy, the service domains will not be able to open
other files created by puppet in /tmp other than the one handed to
them due to the checking of the new open permission.
Good point.
Thanks!
Sean