Puppet's use of tempfiles for capturing use of subprocess I/O

[Daniel J Walsh]

Sean E. Millichamp wrote:
> On Fri, 2008-09-12 at 09:43 -0400, Stephen Smalley wrote:
> 
>> puppet should run in its own domain, and the files created for output
>> should have their own distinct type devoted to this purpose, so that you
>> don't open up access to other files in /tmp unwittingly.  That can be
>> done via policy rules for all files created by puppet in /tmp or via
>> explicit calls to setfscreatecon(3) or setfilecon(3) by puppet for only
>> the specific output files.
> 
> Hi Stephen, thanks for your reply.
> 
> Well, as I understand it, putting Puppet in its own domain and labeling
> the /tmp files so Puppet can only read them and not other files in /tmp
> would certainly be a good thing, but doesn't address my problem.  I'm
> just starting to spend time interacting with SELinux so if I am
> completely misunderstanding something please be patient.
> 
> My problem (in this case) isn't that I want to confine Puppet (that is a
> different project for a different day - maybe), it is that those /tmp
> files Puppet creates and attaches to arbitrary process STDOUT/STDERR
> streams have to be writable by any process in any domain.  Any
> service/command you would run on the command line should be available to
> an admin via Puppet, but in this case instead of sending their output to
> a tty they are sending it to a file.
> 
> Basically, I want to be able to do this:
>  - create the temporary file
>  - chcon the temporary file to allow_all_domains_to_write_to_me_t
>  - attach the files to stdout/stderr and exec whatever the command is
>  - regardless of any policy on the command, it should be able to write
> to allow_all_domains_to_write_to_me_t
> 
> I know that having a context like "allow_all_domains_to_write_to_me_t"
> is probably against the spirit of SELinux, but if such a file context
> exists it would solve my problem.
> 
>> With a recent kernel and a policy that enables the open_perms capability
>> (which I believe will be used in Fedora 10, but isn't on presently in
>> rawhide AFAICS), you can allow domains to inherit and use an open file
>> descriptor provided by the caller without allowing them to directly open
>> the file.  Then policy could allow all of the service domains to inherit
>> and use the open file descriptors to the output files while still
>> preventing them from opening any other output file created in /tmp by
>> puppet.  That is done by way of introducing an "open" permission check
>> on direct opens of files separate from the existing "read" and "write"
>> checks applied on any access of the file.
> 
> This sounds like exactly what I need, except unfortunately I need
> something that will work on existing and older distributions.  Is there
> anyway I can simulate that behavior now with existing SELinux
> implementations?
> 
> Sean
> 
> 
Right and you would

allow domain puppet_tmp_t:file rw_file_perms;

Which would allow every process on the system to read/write these files.

Of course I would suggest that you not use /tmp for this activity since
/tmp is really a USER resource and not a System resource.  You should
never create files by privileged processes in /tmp/ they should be
created in /var/run/puppet or /var/log/puppet.

http://danwalsh.livejournal.com/11467.html



You can generate a policy

# cat puppetout.te

policy_module(puppetout, 1.0)

gen_require(`
	attribute domain;
')

type puppet_log_t;
files_type(puppet_log_t)

allow domain puppet_log_t:file rw_file_perms;


# make -f /usr/share/selinux/devel/Makefile
# semodule -i puppet.pp
# touch /var/run/puppet.log
# chcon -t puppet_log_t /var/log/puppet.log

Go to town.