It seems that there are several reasons for wanting sources,
- fixing bugs yourself, vendors are too slow.
- making local modifications.
- code review, to understand innards for easier bug fixing as
above, for general purposes, and a few replies indicated that
line-by-line inspections actually do get done.
- knowing that other people have been looking over the code
as well lends assurance.
A little vaguely philosophical blather:
The question of just what IS the source comes to mind. For example,
NSC isn't going to give away the code that runs on our routers, and you
probably don't want to review it, and you don't have the tools to fix bugs in
it. However, that's not the level of 'source' you want. Instead, it seems to
me that the 'source' is the packet filters you've set up, for example.
You can inspect them, you can fix bugs in them, you even have a fair chance of
using them to code around a bugs in the underlying software, were one to crop
up. Similarly, I'm sure lots of people on this list have SATAN, some of those
reviewed the source, most are probably pleased to have the source so they can
fix bugs and extend it. The source, however, is perl source, not C code. You
did not, I assume, inspect the sources to perl itself, nor (probably) do most
readers here expect to go fixing bugs in it. Similar remarks apply the
the C compiler used to build your copy of the TIS fwtk.
Here is a theory of Practical Security Software, then:
Network security lives on many levels, from the transistors on the
ethernet chip, through drivers, kernel, application software all the way up
to the configuration information the application reads. At some point, if you
are to trust a chunk of this system, there must be a level for which:
- things below the level don't need to be perfect to keep us ok,
as long as levels above are solid.
- the levels above are all subject to rigorous review and testing,
and at least one level above it is useful for rapid bug-fixing and
If there is no such level, you're dead, because you haven't got a
place to put your trust where it will do you any good. If there is such a
level, the stuff above it is 'the source' that most respondents want to have,
Now, I'm going to claim that good security software works by
carefully defining a layer you can trust, and providing a rigorously
reviewable and testable set of stuff above that layer. To pull an example out
of the air, the TIS fwtk provides a layer of trust in the application proxies
by making them small and simple, and letting the world code inspect them.
The fwtk presumably also ensures that everything above the proxies, the
configuration stuff, is all easy to read, easy to review, testable,
By way of another example, the facility I am working on for my
employer can be trusted not because you can have source, but because you
can (under NDA) look over the test plans, the test results, the design
documents and all that fun stuff, which is in this case far more illuminating
than the source code. On top of the facility is stuff explicitly designed
to be clear, easy to review, etc.
The point here is that what the source buys you a couple of different
things, a layer of trust, and a place to make modifications and fixes. These
are two different things, and they need not be wedded to the same place, it's
perfectly possible to supply trust at one layer and modification/fix
capability a layer up. Furthermore, one can make the case that the bottom
layer that you trust should NOT be subject to modification, since you changes
can potentially break it, and it's the last bulwark between you and the
kernel, or whatever the stuff underneath is that you don't really trust.
Ideally, you'd leave that bottom layer intact, after doing whatever you need
to do to decide that it's trustworthy, and then make changes up above, in the
Perl scripts or the configuration files or what have you.
It is unfortunate that so few vendors will sell you a layer of trust
you can actually trust, so each administrator is left to build at least
the trust with no help.