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 */ -- Homepage: http://www.sesse.net/