Thread: [mod-security-users] SecChrootDir and SELinux

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello, I'm working on building a reverse proxy configuration using
ModSecurity-1.8.7 and Apache 2.0.54 on Red Hat Enterprise Linux v.4 ES.
One of the items I would like to implement is to chroot Apache, and I'm
running into some hassles with the default targeted SELinux policy
(nothing like one security mechanism getting in the way of another).

First a few details:
1.	Apache is custom compiled with ModSecurity statically linked.
To do this, I copied the mod_security.c file to the modules/proxy folder
in the extracted source code for Apache, then added the following flags
to configure:
	  --enable-security --with-module=3Dproxy:mod_security.c

	(note I actually did this via a custom modification of the spec
file for the Apache RPM in Fedora Core 4.  So directories and so forth
will match the Fedora/Red Hat 'way' with /etc/httpd and /var/www, etc.
If anyone is interested in the spec file/SRPM I used for this, let me
know.)

2.	Using Red Hat Enterprise Linux v4, kernel 2.6.9-11.EL, but I
would expect a similar issue on Fedora Core 3 or 4, as I believe that
also has SELinux as an option.  SELinux versions are as follows:
[root@wyrmfire ~]# rpm -qa | grep selinux
libselinux-1.19.1-7
selinux-policy-targeted-1.17.30-2.88

3.	/etc/httpd/conf/httpd.conf contains the following directive:
	SecChrootDir	/var/www

The above configuration works perfectly if SELinux is disabled.  If I
enable SELinux, but set to permissive mode (setenforce 0), I get the
following audit entries in /var/log/messages from SELinux:

Jun 25 13:18:02 wyrmfire kernel: audit(1119730682.328:0): avc:  denied
{ write } for  pid=3D2324 comm=3Dhttpd name=3Dmodsec_chroot.lock =
dev=3Dsda8
ino=3D55751 scontext=3Droot:system_r:httpd_t
tcontext=3Droot:object_r:httpd_log_t tclass=3Dfile
Jun 25 13:18:02 wyrmfire httpd: httpd startup succeeded
Jun 25 13:18:02 wyrmfire kernel: audit(1119730682.769:0): avc:  denied
{ unlink } for  pid=3D2325 comm=3Dhttpd name=3Dmodsec_chroot.lock =
dev=3Dsda8
ino=3D55751 scontext=3Droot:system_r:httpd_t
tcontext=3Droot:object_r:httpd_log_t tclass=3Dfile
Jun 25 13:18:02 wyrmfire kernel: audit(1119730682.770:0): avc:  denied
{ sys_chroot } for  pid=3D2325 comm=3Dhttpd capability=3D18
scontext=3Droot:system_r:httpd_t tcontext=3Droot:system_r:httpd_t
tclass=3Dcapability

A ps -ef | grep httpd afterwards shows that Apache dies here right after
start up.

I ran these audit entries through the very helpful audit2allow program
(see http://www.nsa.gov/selinux) and got the following SELinux suggested
policy additions:

allow httpd_t httpd_log_t:file { unlink write };
allow httpd_t self:capability sys_chroot;

The second line seems straight up, but I'm wondering about the first--it
seems that Apache is being denied access to it's own log files, which
was probably done for a good reason ;-)  Before I go off ignore said
good reason, I wanted to run this by everyone and get some feedback.
Alternatives I see would be to create a new domain just for the
modsec_chroot.lock file in SELinux (non-trivial, requires some dark
SELinux voodoo) or alter the code to write this file to a different
directory that Apache does have access to (not sure if this is feasible
or if such a directory exists).

For completeness, here is the security contexts for the files in
/var/log/httpd:
[root@wyrmfire ~]# ls -laZ /var/log/httpd
drwx------  root     root     system_u:object_r:httpd_log_t    .
drwxr-xr-x  root     root     system_u:object_r:var_log_t      ..
-rw-r-----  root     root     root:object_r:httpd_log_t
access_log
-rw-r-----  root     root     root:object_r:httpd_log_t        error_log
-rw-r-----  root     root     root:object_r:httpd_log_t
rewrite_log

And /etc/httpd:
[root@wyrmfire ~]# ls -laRZ /etc/httpd
/etc/httpd:
drwxr-xr-x  root     root     system_u:object_r:httpd_config_t .
drwxr-xr-x  root     root     system_u:object_r:etc_t          ..
drwxr-xr-x  root     root     system_u:object_r:httpd_config_t conf
drwxr-xr-x  root     root     system_u:object_r:httpd_config_t conf.d
lrwxrwxrwx  root     root     system_u:object_r:httpd_log_t    logs ->
../../var/log/httpd
lrwxrwxrwx  root     root     system_u:object_r:httpd_modules_t modules
-> ../../usr/lib/httpd/modules
lrwxrwxrwx  root     root     system_u:object_r:etc_t          run ->
../../var/run

/etc/httpd/conf:
drwxr-xr-x  root     root     system_u:object_r:httpd_config_t .
drwxr-xr-x  root     root     system_u:object_r:httpd_config_t ..
-rw-------  root     root     root:object_r:httpd_config_t
httpd.conf
-rw-r--r--  root     root     system_u:object_r:httpd_config_t
httpd.conf.dist
-rw-r--r--  root     root     system_u:object_r:httpd_config_t magic
-rw-r--r--  root     root     system_u:object_r:httpd_config_t
ssl.conf.dist

/etc/httpd/conf.d:
drwxr-xr-x  root     root     system_u:object_r:httpd_config_t .
drwxr-xr-x  root     root     system_u:object_r:httpd_config_t ..
-rw-r--r--  root     root     system_u:object_r:httpd_config_t README

Appreciate thoughts/feedback on this.  Once I get this working, I'll be
happy to post a much shorter list of the steps needed to workaround the
default SELinux policy so that can be added to a FAQ somewhere :-)

Thanks,
Jeff Tharp
System Administrator
ESRI - Redlands, CA, USA
http://www.esri.com

=20