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

[Forrest Taylor]

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?

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.

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?

Thanks,

Forrest

[David Caplan]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> Forrest Taylor
> Sent: Saturday, March 10, 2007 11:56 AM
> To: [e-mail]
> Subject: Making a python/shell script run in httpd_t (or some 
> other domain)
>
> 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?

You need to make sure you have all the rules required for your source
domain to transition to your target domain. The unconfined_t domain
generally does not transition; it is designed to run most things in its
domain which has a wide range of permissions (hence the name
"unconfined").

You need these three rules to permit a transition:
allow source_domain target_domain:process transition;
allow source_domain entrypoint_type:file {read getattr execute};
allow target_domain entrypoint_type:file entrypoint;

If you want the transition to be automatic, you also need a
type_transition rule:
type_transition source_domain entrypoint_type:process target_domain;

You can use apol's domain transition analysis to test your policy to
make sure you have all the necessary rules. There is also a good
explanation of domain transitions in the Help menu. (Or Chapter 5 of
_Selinux by Example_ :))

You also probably don't want to run your script in httpd_t, but in a
more restricted domain.
> 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.
>
> 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?
>
> Thanks,
>
> Forrest

[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]

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.