Sean E. Millichamp wrote:
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
Well puppet has problems when it installs files, that have been reported
upstream. Basically it needs to ask the system what the label of a file
it puts on disk and make sure it is correct. I wrote ruby bindings
during the summer for this purpose and hopefully an updated version of
puppet will be available soon. Currently Fedora Infrastructure team is
using restorecond to try to maintain the labels of files provided via
puppet.