Re: thoughts on kernel security issues

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 25 Jan 2005, John Richard Moser wrote:
> > 
> > Sure there is. There's the gain that if you lock the front door but not 
> > the back door, somebody who goes door-to-door, opportunistically knocking 
> > on them and testing them, _will_ be discouraged by locking the front door.
> 
> In the real world yes.  On the computer, the front and back doors are
> half-consumed by a short-path wormhole that places them right next to
> eachother, so not really.  :)

No, the same is true even when the doors are right next to each other.

A lot of worms etc depend on automation, and do one or a few very specific 
things. If one of them doesn't work (not because the computer is _secure_ 
mind you, just some random thing), it's already a more secure setup.

And even if two independent security bugs cause _exactly_ the same
symptoms (ie the exact same exploit works even if either of the bugs still 
remain), having two independent patches that fix them is STILL better. 
Just because the explanation of them is simpler, and the verification of 
them is simpler.

> > Never mind that he still could have gotten in. After all, if you locked 
> > the back door too, he might still have a crow-bar.
> 
> Crowbars don't work in computer security.

Sure they do. They're the brute-force password-cracking. They're the 
physical security of the machine. They are any number of things.

The point being that you will always have holes. Arguing for "there's 
another hole" is _never_ an argument against a small patch fixing one 
problem.

Take it from me - I've been reviewing patches for _way_ too long. And it's
a damn lot easier to review 100 small patches that do simple things and
that have been split up and explained individually byt he submitter than
it is to review 10 big ones.

It's also a lot easier to find the (inevitable) bugs. Either you already 
have a clue ("try reverting that one patch") or you can do things like 
binary searching. The bugs introduced a patch often have very little to do 
with the thing a patch fixes - exactly because the patch _fixes_ 
something, it's been tested with that particular problem, and the new 
problem it introduces is usually orthogonal.

Which is why lots of small patches usually have _different_ bug behaviour
than the patch they fix. To go back to the A+B fix: the bug they fix may
be fixed only by the _combination_ of the patch, but the bug they cause is
often an artifact of _one_ of the patches.

IOW, splitting the patches up makes them
 - easier to merge
 - easier to verify
 - easier to debug

and combining them has _zero_ advantages (whatever bug the combined patch
fix _will_ be fixed by the series of individual patches too - even if the
splitting was buggy in some respect, you are pretty much guaranteed of
this, since the bug you were trying to fix is the _one_ thing you are
really testing for). 

See? 

			Linus