httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: mpm-itk and upstream Apache, once again
Date Sun, 22 Jul 2012 20:54:26 GMT
On Sunday 22 July 2012, Steinar H. Gunderson wrote:
> 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.)

As long as the process has CAP_SETUID, it can switch back to uid 0 and 
write root owned files. But seccomp BPF should be able to fix that.
For FreeBSD, one could use capsicum.

> > 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.

Then, it seems, Jeff is correct: There is no consistent set of 
criteria wether to include or not to include a module. Or maybe the 
criteria change over time (mod_privileges has been added 4 years ago).

> > 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?

Yes, that's the primary argument. And maybe being able to use the same 
hooks in different interesting ways. From a superficial glance, it 
seems that (in addition to the two new hooks already mentioned) 
hooking near ap_run_create_connection into mpm-prefork would take care 
of most of it. But I could be wrong.

> 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.

Sure.

Mime
View raw message