Hey John,
If it hasn't been said before, thanks for the hard work on building a safer
string library. Hopefully it will be a great add on for people who use it
effectively.
I have a question based on some earlier discussion on this thread. If I
understand this correct, it surrounds the issue of simply dieing if the call
is incorrect. Ok, so if something is wrong it fails securely by simply
bailing out. Although this is an excellent approach on the surface of
things, I'm not sure how good this is from a quality of code view. In many
applications you want to recover for a problem, and carry on. Not die.
Especially in critical real-time applications. More inportantly... I would
think obscuring bad coding practices (such as not checking return codes)
should be avoided, and handled with alittle more clarity.
Personally.... I dislike seeing code like (with no offense to deneb):
result = function_1("goofyski",&error);
if (error.type==ILLEGAL_STRING)
{
fprintf(stderr,"Insecure string");
exit(1);
}
In my opinion, it is crucial to check return codes for the SUCCESS status of
a call.. not the failure. In deneb's example.... what if the error was
error.type == NO_MEM_AVAILABLE or something like that. It would miss that
entirely and carry on. Very easily this code is now in a bad state, and can
cause secondary failures. If we planned on failure and had a clean failure
code path, we won't NEED to die... as we should be able to recover.
Now, I think I understand your goals in how the safer string library is
supposed to function. The weakest link is the human factor and you are
wanting to "ease the burden" of the programmer by removing the
security-critical responsibilities and pushing them to the string libraries.
But I would say there must be a happy medium between not offloading
security-critical responsibilities against the issue of bad code design and
bad coding practices.
If someone isn't properly checking return codes.... the quality of the code
will probably show that the developer is also dealing with it incorrectly in
OTHER functions outside of your string library. Which simply means its
passing the buck to a different function to fail later. I don't have an
answer on what the RIGHT way would be to handle this, but obscuring clear
design principles on failing securing with strong failure paths should
always trump simply not exposing return codes to the programmer. Especially
on string functions where it is even more critical.
This isn't new to you... as I note you already responded by saying:
> When potentially security-critical problems come up, I would rather
> just see the program die if there's any significant chance of the
> programmer failing to check the error condition and leaving the
> program in an insecure state.
Instead of simply dieing... is it possible to validate that the programmer
is checking the error condition? (I don't have an answer to that myself.) I
would hate to see movement to a safer string library that actually REMOVES
the ability for developers to build clean failure code paths to allow for
recovery. I hope you see what I am trying to get at.
In any case, keep at it. The suggestions of a callback might make sense, but
I would again lean on the issue of having clearly demarked failure code
paths for recovery. This HAS to be handled by the developer gracefully...
and is an issue about good coding practices (back to the old thread about
education) and shouldn't be obscured with smarter libraries that don't help
in the overall code design.
---
Regards,
Dana M. Epp
----- Original Message -----
From: "John Viega" <viegaat_private>
To: "Giorgio Zoppi (deneb)" <denebat_private>
Cc: <secprogat_private>
Sent: Tuesday, February 11, 2003 3:57 AM
Subject: Re: safestr alpha (Safe C String Library)
> Yes, we're still trying to figure out the mechanism via which we want
> to handle such things. The big problem with returning error codes,
> etc. is that there's a strong tendency to ignore results than indicate
> an error.
>
> When potentially security-critical problems come up, I would rather
> just see the program die if there's any significant chance of the
> programmer failing to check the error condition and leaving the program
> in an insecure state.
>
> We are leaning toward providing a callback for when a "fatal" error
> occurs. The default will be to print an error message and abort. This
> solution gives the programmer some flexibility, and even avoids
> needlessly adding a bunch of additional error conditions to check. On
> the down side, it can be difficult to figure out the exact context of
> failure and recover gracefully.
>
> We'll definitely have some solution in place by the beta series.
>
> John
>
>
> On Tuesday, February 11, 2003, at 07:34 AM, Giorgio Zoppi (deneb) wrote:
>
> > A library when gets error conditions, should toss that error condition,
> > to the programmer. In that *alpha* code you assume that the programmer
> > is stupid, and kill the program when the string arrays aren't safe,
> > at least you should provide a way to check.
> > Cheers,
> > deneb.
> >
>
This archive was generated by hypermail 2b30 : Tue Feb 11 2003 - 10:44:38 PST