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