Making a python/shell script run in httpd_t (or some other domain)

[Stephen Smalley]

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).

-- 
Stephen Smalley
National Security Agency