Re: What do you take for secure programming?

[Valdis.Kletnieks]

On Thu, 05 May 2005 18:31:38 EDT, Dave Aronson said:

> could have a very lengthy thread trying (in vain) to define the exact
> differences between:
>
>  - programmers (and whether it should have one m or two)
>  - coders
>  - systems analysts
>  - software engineers
 (yadda yadda)

One possibly useful metric is that the ability of automated checkers to detect
flaws is related to the level of abstraction the flaw is at.

Errors made at the coder level (fencepost errors, buffer overruns, double free()
errors, dereferencing after free(), and so on) are for the most part detectable
by automated means (C checkers like Splint, and languages like Java detect many
of them at runtime).

The next level up are errors like API issues - was the caller required to verify
the data passed, or does the called function have to do it?  Who frees the memory
that a function malloc()s? These are usually *not* expressible in the language
as part of the API, and usually hand-checking of code is needed to find these
bugs (although automated checkers are making progress here).

At the top are errors at the systems analysis level - where conceptual errors
in the specifications introduce flaws and vulnerabilities.  These are almost
impossible to detect automagically....

[David LeBlanc]

 
> From: Gustavo Rios said:

> Anyhow. What you said about large project i agree with. But i
> am in the arena of writing very specific tools, like my
> version of database competitor for BDB, My kerberos
> implementation, my telnet server, my NIS project, and the
> like. I am writing them alone, i am confident enough for
> such. I do not write down my specification in a strictly
> formal manner, but i have formal perspective in mind. And
> that, dude, that makes a real difference.

So you think you can write a completely proper implementation of telnet or
NIS? I think both of these protocols are fundamentally broken designs.
They're also both good examples of how an overly complex, loose
specification lead to problems. When I talk about the fundamental issues in
creating secure software, telnet is always my example of something where
even if the implementation is perfect, it's still broken.
 
> I have some already done tools i have been using in stressing
> environment. They works like pretty well, no downtime, no
> performance bottleneck that could not be achieved before by
> similar software ...

It's good that you're working towards that goal, but we should be a little
more realistic about what can be done with something that takes more than
one person to create.

> I think you are right, these method does not scale well. The
> more the number of fellows in any given software the lower
> its quality, at least that's my experience.

But that's the challenge - if you can train one developer to write very
robust code, now how do you scale that? This doesn't have to be a given.

> But i have seen large project that are gide by people that
> have no ideia about what they were doing. Much of the
> problems that put even higher pressure on release dates was
> because of software per se, but because of incompetence. That
> leads to higher and higher increase in software complexity.
> since nobody really know what to do, they fired everywhere
> and after started working to cure the bullets damage
> (remenber, bullets theyselfs shot). Funny, isn't it?

Exactly - when software management doesn't know what they are doing, you
then have a problem. It won't be good for security, the health (mental and
otherwise) of the programmers, or quality.

> I believe i am coherent, all i can say is that they works for
> me alone, because i use them. The results of such approach
> may be seen by the users of my software. Whether they works
> for large team project or not, i don't know. At least i hope
> when you say they don't, this may be justified by your own
> experience trying to use them, and if it did not work you are
> supposed to be sure it was a faulty of the method itself and
> no other variable like, incompetent developers, no
> familiarity with that method, and the like.

I think the first thing to do is recognize that you have more factors than
implementation - design, usability, and so on. Then remember that we have
different levels of technique to get different levels of reliability. You
could use the methods of NASA, but code would get written very, very slowly.
The seat of the pants method with bad management is clearly the worst. But
we have a range of methods in-between - extreme programming being an
interesting example.

Single programmer projects are often disasters - peer review adds a lot of
insight, both with respect to correctness and design problems. I could have
a piece of code that's fundamentally correct, but not know some detail of
how that API or OS works - e.g., calling fopen on foo.lpt on a Windows
system leads to problems.