Wed, 23 Feb 2011 21:49:50 +0100 Stefan Fritsch <[email protected]> wrote:
Thanks for your reply. That was really the thing I need to hear. > Hi, > > the item "Mass vhosting version of suEXEC" has been on the wish list > in httpd's STATUS file for many years. However it is not easy to do > without introducing local privilege escalation vulnerabilties. > > On Tuesday 22 February 2011, Alexander GQ Gerasiov wrote: > > Some days ago I found that I'm tired of original suexec which is > > shipped with apache. > > I have two issues: > > > > 1.I'd like to configure it with config file, not with rebuilding, > > because I use modern OS with package system and don't want to > > depend on self-compiled components. > > BTW, you have noticed that there is a version of suexec in Debian > that allows to change the docroot and the run user with a config file? Yep, but it's still not very comfortable to create a config file for every user. And it allows my to specify docroot only. > > > 2.I'd like to use apache2+fcgid+suexec+php5. But with original > > suexec I had to put dumb script to every users docroot, which only > > execs /usr/bin/php-cgi. So I just want to allow suexec execute some > > commands out of docroot tree and owned by the users other that one > > we setuid to. > > Here is the problem. With the standard suexec, a user has to put a > script into a special dir and make it executable to allow suexec to > execute code as that user. That's clearly an opt-in process. Without > the owner check, suexec will execute code as any user above the > limit. There is no opt-in decision required by the user. And suexec > will pass any arguments to the executed program. Therefore, in the > special case that the allowed program is an interpreter, somebody > with access to the httpd run user can execute arbitrary code as > arbitrary user (above the configured user id limit). > > For the same reason, it is a very bad idea to allow to configure a > docroot of "/". Many users will have some scripts in /home/.../bin > with appropriate permissions that are not designed to be setuid save > and will allow an attacker to execute arbitrary code as that user. > > You could argue that the limitation of only allowing the httpd run > user to use suexec would reduce this problem. But configurations > where users can execute arbitrary commands as httpd user are rather > common (e.g. a simple httpd installation with mod_php and > mod_userdir). Also, httpd is a network facing deamon and should have > as little privilege as possible. Your suexec introduces these > problems just by being installed on a machine, even if it is not used > by the httpd configuration. > > There has been some lengthy discussion about this topic at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499191 . You should > probably read it. Ok, I see the problem you're trying to avoid. It's not very serious for my installation (since I trust www-user, and I hope there will be no arbitrary code execution in httpd itself =)). I'll look at this closer next time I have some free time and try to make some solution. Which would be correct at least for common installations. I don't think that this should be the silver bullet anyway. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail: [email protected] Jabber: [email protected] Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
