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

[Sean E. Millichamp]

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