>>>>> "Darren" == Darren Reed <avalon @
>>>>> "Gareth" == Gareth Howell <garethh @
Gareth> On point one, I would trust LINUX (or indeed any other freely available
Gareth> and widely used source code O/S) better than any non B class certified
Gareth> commercial product because there is sufficient public scrutiny of the
Gareth> source code to cause any such errors to either be eliminated, or at
Gareth> least be advertised.
Darren> I wonder, has anyone scrutinized it all ?
Darren> Even if the code is well segmented, it may not be a particular routine but
Darren> an interaction that is troublesome. The bigger it gets, the harder it is
Darren> to verify and nothing is getting smaller.
Darren has a good point. I can think of one significant freely
available program (sendmail) that has a long history of security
problems in spite of the wide availability of source code and in spite
of many serious efforts to fix the security holes. Just having source
code available doesn't make something secure.
There is also a big distinction in security risk between the OS kernel
(which in any OS's case I think is relatively small) and between the
run-time libraries and application programs (which is usually
Your best bet (in any event) is to build your firewall around a
ruthlessly minimal system. The only OS issue is how well the OS
supports your being ruthless. Purpose-built secure operating systems
mitigate this to some extent, but keeping separate functions separate
and only doing firewall things on a firewall can minimize or eliminate
the need for the extra complexity of a secure OS.
My bias is towards using Linux in firewalls. Working from an install
kit or rescue disk you can build a quite spiffy firewall that boots
and runs totally from a floppy disk. It works out to be pretty easy
to yank code out of the C runtime libraries, and you don't need a
shell, network daemons, or sendmail to run a firewall. Or even a disk
drive beyond the floppy you boot from.