This makes absolute sense, but I don't see how we-without-source can
live in such a world. Even if I do have source, a "user" can't verify
every program--even assuming the programs could be verified by their
authors. :-) For example, you state:
> b) a chrooted process cannot un-chroot itself[...]
How can I know this? My firewall kernel is 704K code and 117K "data".
Theoretically, I eliminated lots of junk--my config file is 32 lines.
This is a major piece of code to trust. Considering how it was
written and is maintained, I am a fool to trust it.
You raise very valid points. I wish I had good answers.
Most popular summaries of the Orange Book focus on the feature lists
for each level: C2 has auditing, B1 has mandatory access controls, etc.
What they miss is the assurance requirements -- the reasons for
believing that the system really works. And -- limited though those
requirements are, because the software engineering field doesn't know
how to do better -- they're about all we've got.
What Marcus and I have been doing is not so much talking about the design
of our particular firewalls, as {t,pr}eaching. That is, we're spouting
off about how systems in general should be designed, both for security
and for correctness. This is nothing new; it's the UNIX philosophy, it's
Software Engineering 101, it's common sense -- and it seems to be totally
unknown to most vendors, who'd rather sell us Feature Creatures.
This isn't the right forum for such lectures, I suspect, and I think I'll
keep quiet for a while. Still, if I survive the process of writing one
book, maybe some day I'll do another on how to write secure software.
The book would be a rewrite of much of the current UNIX security software,
showing how to write the few trusted modules you need, and possibly defining
a few new interfaces. It would, I think, be a useful book. (It would
also be a great way to embarrass myself, when folks spot all the bugs
and security holes in code I'm writing for the whole world to read...)
Btw, if you want to write this book yourself; don't feel shy. There's
no chance I'd even think about starting till next summer at the earliest.
If you can start sooner, please do -- it's a necessary book.
Has anybody performed a risk analysis for their firewall project? I
know about Berferd, but we aren't AT&T, so I assume our risks are much
lower. I'd like to know two things: How likely is an attack for a
typical small company? and How much does feature X reduce the
probability of a break-in? (Sounds like a great niche for an
insurance company: "Cracker Claims, may I help you?" Maybe I should
call Lloyd's.) Given that there are no physical phenomena involved,
it seems like the assessment should be easier than, say, assessing the
likelihood of being killed by a meteor (1:30K, btw).
1:30K? I'd have guessed that the odds were much longer than that. I
don't recall ever hearing of anyone killed by a meteor. Are you factoring
in another dinosaur killer?
Bill Cheswick described some of his risk analysis in his paper describing
the design of our current firewall. It's not quantitative, though.
--Steve Bellovin
|
|
