mod_hostinglimits and setuid

[boris]

Hello!

As you have a patched kernel, I think it will be a great feature to allow mod_hostinglimits to setuid apache process to the user of the specified LVE and then setuid it back to the unprivileged user (in the way mod_hostinglimits escapes the LVE).
This can have a lot of security holes, but I believe that correct implementation can .

[iseletsk]

Boris,

We originally though about it, and even implemented it. Yet, then just by looking at it, we understood just how huge of a security hole such approach is.
The ability for apache user to switch to arbitrary user & back is just too huge a hole, that will be abused by hackers.

[boris]

So maybe you can implement something similar to mpm-itk for apache with this functionality and pack it to your repository? Processes run with setuid capability, when the request is parsed mpm or mod applies LVE and SecureLVE limits, setuids and drops setuid capability, and when a request (or all requests in keepalive-session corresponding to the current user) are processed, kills current apache process.

[iseletsk]

I am sorry, but in my opinion, MPM-itk is one big security nightmare by design, that also has terrible performance.
Running as root, switching to arbitrary uid from inside apache is just too big of an issue., that should be too easy to abuse.

[boris]

You are right here, this can be a security issue -- but we allow FTP and SSH servers to run as root before user authentication completes; we run one MySQL server for all users, that can easily be DoS-attacked.
Killing the process after each keepalive request processes is a big performance overhead, but php-cgi has much bigger permormance overhead -.it fork()s, execve()s two times, setuid()s and exit()s.
Or do you recommend to use php-fcgi and forget about mod_php and php-cgi?

[iseletsk]

If you look at the code for SSH & FTP -- it is very simple (the authentication part):
check credentials/drop priviledges.
You have to keep surface of attack as small as possible.

This is not true with ITK -- apache does a lot of things between accepting request & processing virtual host. So, it is much more dangerous.

Also, while php-cgi is slower then MPM ITK, if you add up static HTML serving by ITK -- you will get better performance with MPM Worker + PHP as cgi then with ITK (though I have seen people putting nginx in front to overcome that).
Also, in terms of performance suPHP is better then php as cgi, and mod_fcgid is comparable in speed with mod_php (though it requires more RAM).

[boris]

I can agree that httpd request parsing part is difficult.
Everything other is configuration and mpm related that is much more difficult to exploit.

I will try using php-fcgi on my test server to compare it with mpm-itk.