On Tue, Apr 16, 2002 at 11:31:12AM -0400, Perry E. Metzger wrote:
>
> Greg Stein <gstein@lyra.org> writes:
> > There is nothing to support that Apache has problematic buffer overflows.
>
> Let me get very very blunt right now. You want to get Microsoft's
> reputation here? Because we know what those guys are like.
>
> You don't get anywhere by putting your head in the sand. There is a
> reason that people come out with large scale security advisories all
> the time, and it is because application programmers treat the security
> issue like a giant fat joke.
Don't even attempt to go down this road. I don't need your lecturing.
I never said that I was putting my head in the sand. I never said security
doesn't matter. I simply stated that you are on unproven ground.
Apache's architecture/design takes a lot of care to avoid buffer overruns.
Most of the attacks that we see are at the application level -- crap like
CSS or not escaping shell characters or whatever. I'm happy to hear about
problems, but broad unfounded generalizations don't please me.
>...
> To you the security issues may be a giant joke ("who cares about
Don't put words in my mouth.
I do care about security, but I also feel you are overstating the
vulnerability. Yes, we have issues related to code size and the operational
user on the server. Pretty much anything we do will be subject to the "code
size and new code" issue. The user on the server is, of course, a different
matter: one system user shared by users, or per-user system users? I would
stipulate that the one-vs-many is only relevant if you have multiple
repositories with different access policies, or fine-grained access control
within a single repository. But for a single repository with a simple global
"can you write to it?" access control, then a single system user is fine.
When I said I felt you were overstating the problem, it is because I do not
believe we have issues related to the use of HTTP/SSL (iow: the choice of
HTTP/SSL is not inherently a poor choice).
>...
> Steve Bellovin did a great study a while back of CERT
> advisories. There are almost never attacks these days based on bad
> crypto. They're almost always based on buggy code. Less code being run
> means fewer places for there to be bugs.
Agreed. But the code size isn't going to magically shrink. Thus, we simply
need to mitigate the effects of the size of the code base.
ra_pipe is one approach, and would certainly make ssh tunnelling possible.
Another entirely viable alternative is a custom HTTP server whose sole
purpose is to talk to libsvn_(repos|fs). That is: you remove Apache,
mod_dav, and mod_dav_svn, then add this new chunk (which is hopefully
smaller than the former :-). Of course, this could all be coded in C or
somesuch, but I think it would be interesting to see somebody attempt to
write such a beast in Python, using the SVN/Python bindings. (or Perl or
Java or whatever)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 16 23:38:29 2002