Problem - Kevin Tafuro

Most of the security patches issued today are issued to eliminate surprises because
there are no specifications for the underlying code. As a profession, we write too
much surprising code.
I could go on, but I hope my points are clear: there are some real problems in the
way software is being produced, and those problems lead to some serious—and
expensive—problems. However, problem-free software and absolute security are
almost always beyond our reach in any significant software project, so the next best
thing is to identify and reduce the risks. Proven approaches to reduce these risks
include using established methods of software engineering, exercising care in design
and development, reusing proven software, and thinking about how to handle potential
errors. This is the process of assurance—of building trust in our systems. Assurance
needs to be built in rather than asserted after the software is finished.
That’s why this book is so valuable. It can help people write correct, robust software
the first time and avoid many of the surprises. The material in this book can help you
provide a network connection with end-to-end security, as well as help you eliminate
the need to patch the code because you didn’t add enough entropy to key generation,
or you failed to change the UID/GID values in the correct order. Using this
code you can get the environment set correctly, the signals checked, and the file
descriptors the way you need them. And along the way, you can read a clear, cogent
description about what needs to be set and why in each case. Add in some good
design and careful testing, and a lot of the surprises go away.
Are all the snippets of code in this book correct? Well, correct for what? There are
many other things that go into writing reliable code, and they depend on the context.
The code in this book will only get you partway to your goal of good code. As
with any cookbook, you may need to adjust the portions or add a little extra seasoning
to match your overall menu. But before you do that, be sure you understand the
implications! The authors of this book have tried to anticipate most of the circumstances
where you would use their code, and their instructions can help you avoid
the most obvious problems (and many subtle ones). However, you also need to build
the rest of the code properly, and run it on a well-administered system. (For that, you
might want to check out some of the other O’Reilly books, such as Secure Coding by
Mark Graff and Kenneth van Wyk, and Practical Unix and Internet Security by Simson
Garfinkel, Gene Spafford, and Alan Schwartz.)
So, let’s return to those four categories of programmers. This book isn’t likely to help
the group of people who are perpetually unclear on the concepts, but it is unlikely to
hurt them. It will do a lot to help the people who need guidance and examples,
because it contains the text as well as the code. The people who write good software
most of the time could learn a lot by reading this book, and using the examples as
starting points. And the experts are the ones who will readily adopt this code (with,
perhaps, some small adaptions); expert coders know that reuse of trusted components
is a key method of avoiding mistakes. Whichever category of programmer you
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Foreword | xv