[mod-security-users] SecChrootDir and SELinux
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
[mod-security-users] SecChrootDir and SELinux
|
From: Jeff T. <jt...@es...> - 2005-06-27 21:42:47
|
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
|