On Mon, 2007-03-12 at 08:53 -0400, Stephen Smalley wrote: > On Sat, 2007-03-10 at 09:55 -0700, Forrest Taylor wrote: > > I am trying to make a python script run in the httpd_t domain on RHEL5 > > RC4. I have assigned the script the httpd_exec_t type. I searched the > > archives, and I saw an earlier post that stated that I should use the -E > > option to python: > > > > #!/usr/bin/python -E > > > > I see the same entry in python scripts like setroubleshootd. However, > > when I try to run my script (or setroubleshootd, for that matter) > > directly, it runs in unconfined_t. I have the same problem with shell > > executables. Any tips? > > unconfined_t transitions to initrc_t upon running an init script, and > then initrc_t transitions to the appropriate domain (e.g. httpd_t) upon > executing the program. That has been the case for Fedora Core 4 and > later, I believe. There is no direct transition from unconfined_t to > httpd_t. Providing such direct transitions, as in Fedora Core 3, caused > a number of problems in cases where you didn't actually want to run a > program in the same domain when directly run by the user vs. when run by > an init script. You can of course always force the transition via > runcon -t, if allowed by policy. > > > run_init will run as expected, but it does also ask for the root > > password. I know that I could change the pam.d/ entry, but I don't want > > to do that at this point. > > runcon should work for you as long as you start unconfined and the > program has the right type. > > > I created an init script that simply calls the executable. This works > > as expected, as long as the script starts with the interpreter (e.g., > > #!/bin/bash). If I leave out that line, it does not transition. Any > > idea why? > > If you trace the execution, you'll see there is a difference in what > happens for those two situations. With the #!/bin/bash header, the > kernel can directly launch the interpreter upon exec of the script, and > thus we can perform a domain transition based on the script there > (although you should only ever do that when the calling domain is more > trusted than the called domain, since script execution has an inherent > race condition and scripts are so susceptible to caller influence). > Without the header, the kernel will reject the script upon direct exec, > and the shell falls back to exec'ing the intepreter with the script as > an argument, at which point the kernel doesn't see it at all as relevant > to the exec call (thus no domain transition). Of course, someone could instrument the shell to call security_compute_create(3) and setexeccon(3) in the latter case to emulate the domain transition, similar to runcon -c. The shell would need to gracefully fall back if denied permission though, as it often won't be able to do that when run in a confined domain. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
