httpd controls ?

[Jeremy Ardley]

Hi,

I am experimenting with cgi-bin perl scripts to set specific user's 
passwords. The scripts correctly generate passwords when run from the 
bash prompt but silently do nothing when invoked on the web page.

I assume this is a selinux issue and would like some pointers.

1.Is letting a cgi script change passwords a good idea?
2. If it is safe, how do I persuade selinux to let it happen?

Thanks

Jeremy

[Christofer C. Bell]

On Wed, 30 Mar 2005 17:55:36 +0800, Jeremy Ardley <jeremy(a)ardley.org&gt; wrote:
>  Hi,
>  
>  I am experimenting with cgi-bin perl scripts to set specific user's
>  passwords. The scripts correctly generate passwords when run from the
>  bash prompt but silently do nothing when invoked on the web page.
>  
>  I assume this is a selinux issue and would like some pointers. 
Check /var/log/messages for 'avc: denied' messages.  If you don't see
any, this is not an SELinux issue.  If you do see these messages, then
see below.
 
>  1.Is letting a cgi script change passwords a good idea? 
This is more religious issue than anything else, in my opinion.  I
wouldn't allow it, personally.

>  2. If it is safe, how do I persuade selinux to let it happen? 
Look into use of the audit2allow utility for converting denied
messages into rules that allow the behavior that was denied. The the
short of it is:

# cd /etc/selinux/targeted/src
# audit2allow -d -l -o domains/misc/local.te && make load

Repeat until your script works and then clean up the local.te file's
formatting (not necessary).  The long of it (and a good read) is the
Red Hat Enterprise Linux 4 SELinux Guide
(http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/).
 I'd suggest reading that, specifically section II before doing what
I've suggested here to make sure you have a full understanding of
what's going on.

Note that you are peeling back layers of SELinux protection by doing
this (by granting permissions rather than denying them).  In worst
case, this part of your system (in this case CGI scripts) will have
the same basic Linux DAC (discretionary access controls) protection
that you've been using since before SELinux was available.  You can't
make your system less secure than you would be without SELinux using
audit2allow, you can only put yourself in a state where SELinux is
effectively disabled.

-- 
Chris

"Build a man a fire and he will be warm for the rest of the night.  Set
a man on fire and he will be warm for the rest of his life."  -- Unknown

[Stephen Smalley]

On Wed, 2005-03-30 at 09:32 -0600, Christofer C. Bell wrote:
>  Look into use of the audit2allow utility for converting denied
>  messages into rules that allow the behavior that was denied. The the
>  short of it is:
>  
>  # cd /etc/selinux/targeted/src
>  # audit2allow -d -l -o domains/misc/local.te && make load
>  
>  Repeat until your script works and then clean up the local.te file's
>  formatting (not necessary). 
The problem with the above sequence is it will directly allow those
permissions to the original domain of the script; hence, all CGI scripts
would end up having those permissions.  Better to define a separate
httpd_passwd_t domain modeled after the passwd_t domain in the strict
policy and set up a domain transition into this domain only for the
script in question.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Christofer C. Bell]

On Wed, 30 Mar 2005 10:35:22 -0500, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Wed, 2005-03-30 at 09:32 -0600, Christofer C. Bell wrote:
>  > Look into use of the audit2allow utility for converting denied
>  > messages into rules that allow the behavior that was denied. The the
>  > short of it is:
>  >
>  > # cd /etc/selinux/targeted/src
>  > # audit2allow -d -l -o domains/misc/local.te && make load
>  >
>  > Repeat until your script works and then clean up the local.te file's
>  > formatting (not necessary).
>  
>  The problem with the above sequence is it will directly allow those
>  permissions to the original domain of the script; hence, all CGI scripts
>  would end up having those permissions.  Better to define a separate
>  httpd_passwd_t domain modeled after the passwd_t domain in the strict
>  policy and set up a domain transition into this domain only for the
>  script in question. 
That's a very good point and really bears spelling out.  How would one
go about creating the new domain and then implementing the proper
transition for just one set of CGI scripts?  I ask because I (was)
running Open WebMail and ran into the case where I needed to
effectively disable SELinux controls over all CGI scripts to allow OWM
to run.  I would have preferred the case where these controls were
removed *only* for the relavent scripts, allowing the remaining
scripts to keep the protections afforded by the default policy.

-- 
Chris

"Build a man a fire and he will be warm for the rest of the night.  Set
a man on fire and he will be warm for the rest of his life."  -- Unknown

[Stephen Smalley]

On Wed, 2005-03-30 at 10:03 -0600, Christofer C. Bell wrote:
>  That's a very good point and really bears spelling out.  How
> would one
>  go about creating the new domain and then implementing the proper
>  transition for just one set of CGI scripts?  I ask because I (was)
>  running Open WebMail and ran into the case where I needed to
>  effectively disable SELinux controls over all CGI scripts to allow OWM
>  to run.  I would have preferred the case where these controls were
>  removed *only* for the relavent scripts, allowing the remaining
>  scripts to keep the protections afforded by the default policy. 
Easiest way to create a domain presently is to copy an existing one and
edit it, using your favorite filter to replace all occurrences of the
old prefix with a new one.  By introducing a separate _exec_t type for
the new domain (e.g. httpd_passwd_exec_t) and assigning that type to the
particular CGI script in question (manually with chcon or via restorecon
after updating your file_contexts), you only affect that particular
script.

Possible resources:
The RHEL4 SELinux Guide, 
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
- Understanding and Customizing the Apache HTTP SELinux Policy, 
http://fedora.redhat.com/docs/selinux-apache-fc3/
- Sourceforge SELinux HOWTOs
http://sourceforge.net/docman/?group_id=21266
- SELinux: NSA's Open Source Security Enhanced Linux by Bill McCarty,
http://www.oreilly.com/catalog/selinux/
- Tresys Technology Policy Writing Course Slides,
http://www.tresys.com/selinux/selinux-course-outline.html
- Configuring the SELinux Policy,
http://www.nsa.gov/selinux/papers/policy2-abs.cfm

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Colin Walters]

On Wed, 2005-03-30 at 10:03 -0600, Christofer C. Bell wrote:

>  That's a very good point and really bears spelling out.  How
> would one
>  go about creating the new domain and then implementing the proper
>  transition for just one set of CGI scripts?  I ask because I (was)
>  running Open WebMail and ran into the case where I needed to
>  effectively disable SELinux controls over all CGI scripts to allow OWM
>  to run.  I would have preferred the case where these controls were
>  removed *only* for the relavent scripts, allowing the remaining
>  scripts to keep the protections afforded by the default policy. 
Dan has written a new domain "httpd_unconfined_t" and corresponding
httpd_unconfined_script_exec_t which I believe is in the latest rawhide.
You can then mark specific CGI scripts such as ones that change user
passwords like so:

chcon -t httpd_unconfined_script_exec_t /path/to/my/passwd.cgi

Then the script will be unconfined when executed by httpd.  Note that in
general this is fairly dangerous if the script is actually written in a
language like Python, since a malicious httpd_t process could set a
number of environment variables like PYTHONPATH before executing the
script which could easily lead to a compromise of the unconfined script.
I can't think of a good solution for this other than writing your own
little C program.  Probably we need a specialized interpreter,
e.g. /bin/envexec which would take a list of environment variables to
preserve, and you could write a little script like:

#!/bin/envexec 
/var/www/cgi-bin/myscript.cgi

Then you make that file executable and make its type be
httpd_unconfined_script_exec_t.  

Maybe someone can think of a better way to create wrappers for cleaning
the environment without actually writing a new little C program.

[Hongwei Li]

> > 2. If it is safe, how do I persuade selinux to let it happen?
>
>  Look into use of the audit2allow utility for converting denied
>  messages into rules that allow the behavior that was denied. The the
>  short of it is:
>
>  # cd /etc/selinux/targeted/src
>  # audit2allow -d -l -o domains/misc/local.te && make load
>
>  Repeat until your script works and then clean up the local.te file's
>  formatting (not necessary).  The long of it (and a good read) is the
>  Red Hat Enterprise Linux 4 SELinux Guide
>  (http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/).
>   I'd suggest reading that, specifically section II before doing what
>  I've suggested here to make sure you have a full understanding of
>  what's going on.
>  
I have a question about what you suggested.  My system is working
normally, but I'd like to know more about audit2allow.  My system (fc3,
selinux enforced, targeted) does not have src under /etc/selinux/targeted/
that has only:  booleans  contexts  policy

and I could not find audit2allow, even from the web site you gave above.

Could you provide more information about it? or any links?

Thanks!

Hongwei Li

[Stephen Smalley]

On Wed, 2005-03-30 at 09:47 -0600, Hongwei Li wrote:
>  I have a question about what you suggested.  My system is working
>  normally, but I'd like to know more about audit2allow.  My system (fc3,
>  selinux enforced, targeted) does not have src under /etc/selinux/targeted/
>  that has only:  booleans  contexts  policy
>  
>  and I could not find audit2allow, even from the web site you gave above.
>  
>  Could you provide more information about it? or any links? 
Policy sources aren't installed by default, as you don't need them
unless you are customizing policy beyond the level of boolean settings.
To install the sources, do:
	yum install selinux-policy-targeted-sources

audit2allow is part of policycoreutils and is located in /usr/bin. 
audit2allow --help will display the usage.  A man page was added to the
upstream package in version 1.22, but that wouldn't be in FC3.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Christofer C. Bell]

On Wed, 30 Mar 2005 09:47:41 -0600 (CST), Hongwei Li <hongwei(a)wustl.edu&gt; wrote:
>  
>  I have a question about what you suggested.  My system is working
>  normally, but I'd like to know more about audit2allow.  My system (fc3,
>  selinux enforced, targeted) does not have src under /etc/selinux/targeted/
>  that has only:  booleans  contexts  policy
>  
>  and I could not find audit2allow, even from the web site you gave above.
>  
>  Could you provide more information about it? or any links? 
You simply need to install the selinux-policy-targeted package.  You
can do this with the default yum configuration as the package is part
of the Core distribution.

[cbell@circe ~]$ rpm -qi selinux-policy-targeted-sources
Name        : selinux-policy-targeted-sources  Relocations: /usr
Version     : 1.17.30                           Vendor: Red Hat, Inc.
Release     : 2.90                          Build Date: Thu 17 Mar
2005 02:57:18 PM CST
Install Date: Fri 25 Mar 2005 05:05:18 AM CST      Build Host:
tweety.build.redhat.com
Group       : System Environment/Base       Source RPM:
selinux-policy-targeted-1.17.30-2.90.src.rpm
Size        : 462996                           License: GPL
Signature   : DSA/SHA1, Wed 23 Mar 2005 10:39:28 AM CST, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : SELinux example policy configuration source files
Description :
This subpackage includes the source files used to build the policy
configuration.  Includes policy.conf and the Makefiles, macros and
source files for it.

The audit2allow utility should be part of the policycoreutils package.

[cbell@circe ~]$ rpm -qf /usr/bin/audit2allow
policycoreutils-1.18.1-2.10

-- 
Chris

"Build a man a fire and he will be warm for the rest of the night.  Set
a man on fire and he will be warm for the rest of his life."  -- Unknown