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-----