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

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

Ivan,
Aha, thanks you gave me a good pointer...I'd overlooked the
SecChrootLock directive.  I installed the SELinux policy sources
(up2date selinux-policy-targeted-sources, good idea not to do this on a
production box) and did some digging. The sources for the default
targeted policy are installed to /etc/selinux/targeted/src -- I'll call
this $SELINUXSRC

Looks like the juicy part of the Apache-specific SELinux config is
located in $SELINUXSRC/policy/domains/program/apache.te.  Looking
through this, I can see the default policy is actually fairly generic.
One thing that looked promising was the following pair of lines:
# Creation of lock files for apache2
lock_domain(httpd)

This is a macro and is defined in
$SELINUXSRC/policy/macros/global_macros.te:
define(`lock_domain', `
type $1_lock_t, file_type, sysadmfile, lockfile;
file_type_auto_trans($1_t, var_lock_t, $1_lock_t, file)
')

Hence, I can see that Apache is being granted access to var_lock_t.
This file context is mapped in
$SELINUXSRC/policy/file_contexts/types.fc:
/var/lock(/.*)?                 system_u:object_r:var_lock_t

Aha...so Apache should have access to /var/lock.

So I added SecChrootLock /var/lock/modsecurity-chroot.lock and tested.
This works, but I still get the chroot audit entry:
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

So I need to grant Apache access to chroot itself.  This requires
customizing the SELinux policy.  A good reference to doing this voodoo
is
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guid
e/selg-section-0120.html

Basic cookbook steps:
1. Install latest selinux-policy-targeted-sources RPM.  Best to install
this on a separate box.  If you must install on a production system,
make sure to remove once you are done.
2. Backup existing policy
   cd /etc/selinux; tar cvfz /root/backuppolicy.tgz targeted/policy
targeted/contexts targeted/booleans
3. Add our customization
   echo 'allow httpd_t self:capability sys_chroot;' >>
$SELINUXSRC/policy/domains/misc/local.te
4. cd $SELINUXSRC; make load
   (note you will get an error if SELinux is not currently enabled on
the system you run this on.  If building on a separate system, this
error can be safely ignored)
5. If building on a separate system, package up the new policy
   cd /etc/selinux; tar cvfz /root/newpolicy.tgz targeted/policy
targeted/contexts targeted/booleans
   Copy newpolicy.tgz to your production system and extract to
/etc/selinux
6. In either case, reload the policy
   touch /.autorelabel; reboot
   (note this will take a while, depending on the number of files and
size of the filesystems.  Take this opportunity to enjoy your beverage
of choice :-)

After the reboot, I started Apache and confirmed that the chroot worked
as expected.  So this is solved.  I still think the default SELinux
Apache policy is too generic...I may try customizing further to tighten
everything down to only what is needed for this system to function as a
reverse proxy.

Hope this helps others,
Jeff Tharp
System Administrator
ESRI - Redlands, CA, USA
http://www.esri.com
=20
> -----Original Message-----
> From: Ivan Ristic [mailto:iv...@we...]=20
> Sent: Monday, June 27, 2005 3:38 PM
> To: Jeff Tharp
> Cc: mod...@li...
> Subject: Re: [mod-security-users] SecChrootDir and SELinux
>=20
> Jeff Tharp wrote:
> > Hello, I'm working on building a reverse proxy configuration using
> > ModSecurity-1.8.7 and Apache 2.0.54 on Red Hat Enterprise=20
> Linux v.4 ES.
> > One of the items I would like to implement is to chroot=20
> 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).
>=20
>    Assuming the Apache targeted policy was created without chroot
>    in mind, do you think some of the problems you are experiencing
>    are there because e.g. the paths are different?
>=20
>=20
> > Jun 25 13:18:02 wyrmfire kernel: audit(1119730682.328:0):=20
> 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):=20
> 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
>=20
>    By default, mod_security 1.8.x creates a temporary file,
>    modsec_chroot.lock, in ${ServerRoot}/logs/. Could it be that your
>    Apache configuration is such that this falls where it shouldn't?
>=20
>    You can try using the SecChrootLock directive to explicitly tell
>    mod_security where to put the lock file.
>=20
>    FYI, I will probably remove the need to create the lock file in
>    mod_security 1.9.x. If you want I can do it sooner rather than
>    later.
>=20
>    But we may still try to figure out the problem, and learn something
>    about SELinux along the way ;)
>=20
>=20
> > allow httpd_t httpd_log_t:file { unlink write };
>  > ...
>  > it
>  > seems that Apache is being denied access to it's own log=20
> files, which
>  > was probably done for a good reason ;-)  Before I go off=20
> ignore said
>=20
>    Since unlink & write in the log folder are not allowed, what is
>    allowed? How will Apache create the logs if the operation is not
>    allowed? :)
>=20
> --=20
> Ivan Ristic
> Apache Security (O'Reilly) - http://www.apachesecurity.net
> Open source web application firewall - http://www.modsecurity.org
>=20