Karl wrote:
>
> "Stuart Celarier" <SCelarier@corillian.com> writes:
> > Allowing one user to deprive all other users of
> > the server will at least tick off the users, and in the hands of a
Bad
> > Guy (TM) allows him stage a denial of service attack.
>
> Huh? No one is arguing in favor of this.
I understood Garrett to say that the longstanding policy is "we don't
explicitly check for valid arguments to ANY API calls, if a caller
passes us bogus data (i.e. a NULL pointer to a function defined to not
take NULL pointers, etc) we crash...."
> We had a technical question
> on *where* the input should be validated, not a policy question on
> *whether* it should be validated.
Well, no, actually Garrett is saying this is a policy question on
whether it should be validated.
And I am pointing out that a consequence of this policy is that puts any
software system at risk. Reliability risks are serious security risks.
But, hey, at least an assert is limited to just bringing the server
down. Not validating input to any API can presents a range of other
threats to the system.
> The direct repository-filesystem APIs are not a security boundary,
> because anything using them also has direct access to the
repository...
Thanks, I didn't know that. But Garrett's comment was this policy
applies to ANY (his emphasis) API calls. That caught my attention.
> ...and any server that wants to stay running needs to have code that
uses
> the APIs properly.
Absolutely: the server needs a *guarantee* that that all code uses its
APIs properly. The security of the system is measured by its weakest
link. So how do you guarantee that every API call in a complex software
system is proper?
> There is still a useability/friendliness question
> of whether assert() vs error-return is best for the server code, but I
> don't think it's a question on which security theory per se has much
> bearing.
I see it from a different perspective. A failed assert causes the server
to call abort. That allows one user to deny service from all users and
all repositories on the server. With hundreds of users on a server, that
is a security issue, not a usability or friendliness question.
But what Garrett said is that using any method to validate input to any
API contradicted the policy that's been in place for as long as he can
remember. That's arguing against using either assert or returning an
error. Maybe I didn't understand the comment, or maybe the case is
overstated, but that policy does seem to invite major security risks.
What benefits justify taking those risks?
Best regards,
Stuart
Stuart Celarier | Corillian Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 16 19:59:48 2006