httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steinar H. Gunderson" <>
Subject Re: mpm-itk and upstream Apache, once again
Date Sun, 22 Jul 2012 20:18:12 GMT
On Sun, Jul 22, 2012 at 09:57:18PM +0200, Stefan Fritsch wrote:
> On reason may be that (at least in theory), mod_privileges is more 
> secure: Under Solaris you cannot get uid 0 unless you already have all 
> privileges, so an exploited httpd with mod_privileges does not give 
> you root. Under Linux however, CAP_SETUID is equivalent to full 
> unrestricted root, because it allows you to write to root owned files 
> (like /etc/crontab or /root/.ssh/authorized_keys).

It is possible to set prctl(PR_SET_KEEPCAPS, 1) and then setuid() to a
non-root user and still keep the privileges. This would remove the write to
/etc/crontab; I am unsure what happens in practice if the process does
goes back to uid 0 via setuid(), but in Linux 3.5 or newer, we can disallow
that through a seccomp BPF filter. (Arguably this does not help FreeBSD,
Solaris or any other non-Linux OS. Also, Linux 3.5 was only released this
week, and thus needs some more time before it gets into the hands of a
typical server admin.)

> It also a question of the expected maintenance overhead and the 
> available man-power. For example, according to Debian's popcon, 
> mod_fcgid has around three times as many users as mpm-itk, but it is 
> not part of core httpd either. One of the reasons is that not enough 
> active developers are really interested in mod_fcgid.

Again, this argument does not really make sense considering the inclusion of
mod_privileges, which surely must have a much smaller user base than mpm-itk.

>> If we can really get mpm-itk compilable out-of-tree without Apache
>> patches, that would certainly be a better situation than what we
>> have today.
> Yes, that would be a good thing. It would be even better if it could 
> work as normal (non-mpm) module together with mpm-prefork.

This would probably require some rearchitecting; it's certainly possible
(mod_privileges has already shown that), but it's quite a lot of work,
given that we do expect some cooperation from the MPM currently (e.g. to keep
the scoreboard). What's the primary advantage -- less code duplication?

I think we should try to get mpm-itk working without patching Apache first;
then we can revisit changing it from an MPM into a normal module, if there is
consensus that it would help its inclusion.

/* Steinar */

View raw message