At 10:51 AM 12/11/00 -0500, Vivek Khera wrote:
> >>>>> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes:
>
>SB> Do you think I should include the scenario of making Apache run in
>SB> chroot enviroment in the guide?
>
>That require quite a bit of stuff be crammed into the chroot jail.
>You'll need an entire perl install there, wouldn't you? It might make
>sense for a front-end of a two-tier setup, but the mod_perl instance
>seems to me a bit big. But I guess some people will want the extra
>safety of it. Personally I think it is a bit much to cram into a
>chroot environment.
I believe it is especially the dynamic application portion of a web server
that should be chrooted from the rest of the OS. How many CGI scripts have
you seen that allow /etc/passwd to be read? Or arbitrary commands to be run
on the system versus buffer overflows in Apache?
Even mod_perl and taintmode may not prevent this stuff (well maybe the
arbitrary commands).
Furthermore, I trust Apache to be more secure from buffer overflows than
the Perl interpreter stuck inside Apache (same with mod_php though)...
Language interpreters are large and complex beasts. It's probable that if
they still have memory leaks that some of the bugs in the interpreters
could result in buffer overflow too.
I guess I trust the Apache group to be more diligent on security than Perl
programmers developing custom apps in a highly pressured environment (eg
startups, or whatnot) and that it is the Perl developers (or web app
developers of any genre) which are more likely to have security bugs.
I know very few web developers who have read anything on security beyond a
few security advisories if they made main news... They are so busy learning
Java or the latest Perl trick. I am not saying this is bad, but just
realistic. Of course, I'd rather all developers get educated in security.
But frankly, speaking as a developer, I find myself overwhelmed by the
complexity of the custom apps that are being demanded these days in real
environments, and I can only imagine that there are security bugs in those
apps even with the knowledge I now have.
Why? Because I'm a bad developer? Well, maybe, but it's closer to what
Lincoln Stein says in the W3C Security FAQ. Paraphrased: because all
programs have bugs, large and complex programs have more bugs, and there is
always a probability that some of those bugs are security bugs. The more
complex the program, the more likely there are security bugs.
Of course, as Stas pointed out earlier, he is saying he would still have
just one copy of the Perl interpreter but the hard-copy of it would be in
the chroot jail, so it wouldn't take up a lot of extra space.
So hopefully even space won't be an issue.
Later,
Gunther
