Re: What do you take for secure programming?

Bennett Todd <[email protected]> Thu, 27 Jan 2005 20:14:36 +0000
Newsgroups gmane.comp.security.programming
Message-ID <[email protected]>
Nice broad question:-).

Here are some thoughts on the matter.

Spend time and take care on the problem definition. Examine it at
length, looking for ways to adjust the problem spec so a simpler,
more robust implementation can meet it. The less code you've gotta
write, the fewer security-critical bugs you'll write.

Try to find well-maintained, carefully-analyzed existing components
that can be used to solve parts of the problem. The less code you've
gotta write, the fewer ....

Try to find the highest-level programming language with which you
are confident and comfortable to use to write the remaining bits.
The less code you've gotta write ....

Carefully scrutinize the data flow; concentrate on places where
data crosses trust boundaries, e.g. places where unauthenticated
users present data to trusted services, places where less-privileged
processes present data to more-privileged ones, etc. Be meticulous
about data validation at these points, and try and keep that data
validation logic as simple, clear, clean, and compact as possible.
The less code ....

If you've succeeded, you've written as little code as possible, and
have a simple, clear architecture. So find someone else, who has had
nothing to do with the specification, design, or implementation, and
explain the whole lot to them. Besides the possibility that they
might spot bugs you've overlooked, the simple process of describing
and explaining it forces you to review it in a different way.

Look for auditing tools, ideally ones completely disconnected from
your specific architecture and design; both code-analysis (one-time)
and data-monitoring (permanent watchdog) tools are great safety
nets.

Least privilege is a great technique. In traditional Unix systems,
this can often be implemented by decomposing the system into
processes, that run as distinct, unprivileged uids, where possible
in chrooted jails. Shoving subsystems that do more sophisticated
(==fragile) processing into such jails is an especially big win.

-Bennett
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFB+UusHZWg9mCTffwRAspYAJ9/1riHH8yA494tYA1t2CqR3DaluQCffohb
7G9N0r9HLDEOglKSZGpwWZE=
=vY6R
-----END PGP SIGNATURE-----