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

[Stephen Smalley]

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