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