Bug#607755: apache2: suexec-custom does not allow docroot=/ (trailing slash gets removed)
> This is not a bug, but intentional (see the suexec man page in the
> apache2-suexec-custom package). Setting the docroot setting of suexec
> to / introduces a local privilege escalation vulnerability (at least
> in a non-chrooted environment). Therefore I will not lift this
> restriction.
I understand this, but on the other hand I cannot see why such a
protection should get enforced here; I had to compile a custom suexec
now (or rather re-use a previously compiled one), with the the docroot
setting set to "/". I have not investigated, but the binary is from like
2007 and I might be missing other fixes to suexec because of this.
I think having to install a custom/extra package (apache2-suexec-custom)
and editing a config file in there is non-trivial enough to only get
users who know what they are doing "in danger".
The whole purpose of suexec-custom appears to be that admins do not have
to compile their own binary, but it does not work out in this case.
> However, I do invite you to discuss with me on the debian-apache
> mailing list how a reasonable chroot setup could look like. The result
> could then be documented on [1] and maybe be included in README.Debian
> in a future version.
>
> I think for simple setups without cgi/fastcgi/..., the built-in
> chrootdir directive should simply work (i.e. ChrootDir /var/www).
>
> For more complicated setups, it may be better to have something like
> this: The chroot in e.g. /srv/www, the html data in /srv/www/var/www,
> the DocumentRoot setting in Apache as /var/www. The real /var/www
> outside the chroot then must be a symlink to /srv/www/var/www.
> With such a setup, you can copy stuff into the chroot in a way that
> all paths are identical inside and outside of the chroot. If your
> webapp has some configuration data e.g. in /etc/webapp, make that a
> symlink to /srv/www/etc/webapp and put the files there.
>
> Does this sound like it could work for you?
>
> [1] http://wiki.debian.org/Apache/Hardening
I am using the latter approach, but I have no "/var/www" below the
chroot directory, but am using /var/www as the chroot directly; I have
different document roots below this, like vhosts/foo.
I am using mod_fastcgi and mod_chroot; I have just learnt that ChrootDir
would be available in Apache2 itself, but it does not behave in the same
way like mod_chroot - e.g. it appears to chroot after starting fastcgi
(so the fastcgi processes are outside of the chroot).
(see
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/687275/comments/2
for more information)
My more modern approach is to setup a separate container (OpenVZ) for
each "virtual host" instead; this gets currently backed up by php5-fpm
and nginx. But despite not using Apache in this case, I would like to
improve the process of chrooting it anyway.
Cheers,
Daniel
--
http://daniel.hahler.de/
Reply to: