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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
