Apache is just like all the other projects that grow too big and people get ignorent towards the basic things like fast performance and security.
Apache is kind of PHP of the web servers. It's easy to use, it's supported by every webhost since everybody is used to it, and their developers don't spend too much consideration on security and perfomance. And this is coming from someone who uses Apache and PHP.
If you truly want secure, fast-performance web server, use nginx [wikipedia.org]. It's much better done than Apache.
nginx is a fantastic web server in some cases, but it does have some pretty serious drawbacks, too. It can't easily run CGI scripts, for instance. You get stuck using FastCGI, or SCGI, or PHP, or a half-assed adapter that tries to make your CGI script a FastCGI script, or some other technique. That does no good for those of us with proven and tested CGI scripts that we need to run. So we'll have to use Apache, lighttpd, or one of the many other non-nginx web servers out there instead, until nginx gets its a
*nix systems make it very easy to safely run CGI scripts. If you really have that much trouble creating non-privileged accounts, setting the proper filesystem permissions, using chroot/jails/containers/zones, and setting process limits, then maybe you shouldn't be running a web server in the first place. After all, those are things you should be doing regardless of the technology you're using.
You're probably one of those "Rails kids" he refers to. Like he said, your opinion doesn't matter. It's hard to take
Not being a Linux guru, I thought I had heard repeatedly "Chroots do NOT provide security"? Cant someone who pulls off a privelege escalation escape the chroot?
What about running CGI scripts on a separate virtual machine from the rest of the system? Basically set up a separate web server on that, and have all CGI scripts be executed from there. For access to shared resources, have a "gate keeper" process (or module in the web server) running on the original host which can give out one-time passwords which are then passed onto the script, and which the script can then use to access the resources through that gate keeper. The gate keeper can have a detailed knowledg
Web servers run without root privileges so that the server isn't capable of doing overtly harmful things but you can still modify things that the web server is supposed to modify. That is, it can still mess it up.
If you want to give scripts a separately isolated area, you can use this: http://httpd.apache.org/docs/2.0/suexec.html [apache.org] File system permissions takes over from here.
I don't know too much about SQL servers, but couldn't you probably use kerberos or something instead of directly using database passwor
Cant someone who pulls off a privelege escalation escape the chroot?
Yes, he can. Basically, the trick is to do another chroot to a subdirectory, but without doing the chdir. So now the attacker is in a situation where the current directory is above the root. Here he can keep doing chdir(".."); until he reaches the real root, and then all he needs to do is chroot(".");.
What's worse, this exploit is due to the way how chroot is spec'ed, thus it can't really be fixed by the kernel.
So yes, you can escape a chroot jail if you've got root. However, the point of the chroot jail
The grsecurity [grsecurity.net] patchset lets you prevent the various ways of escaping chroot jails (of which there are a lot), amongst other things. But yeah, fundamentally chroot was never meant to provide security. IIRC it was implemented as a convenience feature for kernel development.
In theory, yes (although in practice, it's extremely rare and difficult). And that's probably why the GP listed other, better, approaches that Linux doesn't support, like FreeBSD Jails, and Solaris' Containers and Zones.
"Because he's a character who's looking for his own identity, [He-Man is]
an interesting role for an actor."
-- Dolph Lundgren, "actor"
Apache is too bloated (Score:0)
Apache is kind of PHP of the web servers. It's easy to use, it's supported by every webhost since everybody is used to it, and their developers don't spend too much consideration on security and perfomance. And this is coming from someone who uses Apache and PHP.
If you truly want secure, fast-performance web server, use nginx [wikipedia.org]. It's much better done than Apache.
nginx has its problems, too. (Score:0)
nginx is a fantastic web server in some cases, but it does have some pretty serious drawbacks, too. It can't easily run CGI scripts, for instance. You get stuck using FastCGI, or SCGI, or PHP, or a half-assed adapter that tries to make your CGI script a FastCGI script, or some other technique. That does no good for those of us with proven and tested CGI scripts that we need to run. So we'll have to use Apache, lighttpd, or one of the many other non-nginx web servers out there instead, until nginx gets its a
Re: (Score:1)
Welcome to 2011, not running CGI scripts is a feature (and a good one at that).
Re: (Score:0)
*nix systems make it very easy to safely run CGI scripts. If you really have that much trouble creating non-privileged accounts, setting the proper filesystem permissions, using chroot/jails/containers/zones, and setting process limits, then maybe you shouldn't be running a web server in the first place. After all, those are things you should be doing regardless of the technology you're using.
You're probably one of those "Rails kids" he refers to. Like he said, your opinion doesn't matter. It's hard to take
Re:nginx has its problems, too. (Score:2)
using chroot/jails/containers/zones
Not being a Linux guru, I thought I had heard repeatedly "Chroots do NOT provide security"? Cant someone who pulls off a privelege escalation escape the chroot?
Re: (Score:1)
What about running CGI scripts on a separate virtual machine from the rest of the system? Basically set up a separate web server on that, and have all CGI scripts be executed from there. For access to shared resources, have a "gate keeper" process (or module in the web server) running on the original host which can give out one-time passwords which are then passed onto the script, and which the script can then use to access the resources through that gate keeper. The gate keeper can have a detailed knowledg
Re: (Score:2)
Re: (Score:1)
Web servers run without root privileges so that the server isn't capable of doing overtly harmful things but you can still modify things that the web server is supposed to modify. That is, it can still mess it up.
If you want to give scripts a separately isolated area, you can use this: http://httpd.apache.org/docs/2.0/suexec.html [apache.org] File system permissions takes over from here.
I don't know too much about SQL servers, but couldn't you probably use kerberos or something instead of directly using database passwor
Re: (Score:3)
Cant someone who pulls off a privelege escalation escape the chroot?
Yes, he can. Basically, the trick is to do another chroot to a subdirectory, but without doing the chdir. So now the attacker is in a situation where the current directory is above the root. Here he can keep doing chdir(".."); until he reaches the real root, and then all he needs to do is chroot(".");.
What's worse, this exploit is due to the way how chroot is spec'ed, thus it can't really be fixed by the kernel.
So yes, you can escape a chroot jail if you've got root. However, the point of the chroot jail
Re: (Score:0)
The grsecurity [grsecurity.net] patchset lets you prevent the various ways of escaping chroot jails (of which there are a lot), amongst other things. But yeah, fundamentally chroot was never meant to provide security. IIRC it was implemented as a convenience feature for kernel development.
Re: (Score:2)
A proper SELinux (or AppArmor, I'd imagine) policy would also serve to confine them in their box.
Re: (Score:1)
Re: (Score:0)
In theory, yes (although in practice, it's extremely rare and difficult). And that's probably why the GP listed other, better, approaches that Linux doesn't support, like FreeBSD Jails, and Solaris' Containers and Zones.