Puppet's use of tempfiles for capturing use of subprocess I/O
Sean E. Millichamp
sean at bruenor.org
Fri Sep 12 15:58:39 UTC 2008
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
More information about the selinux
mailing list