Re: thoughts on kernel security issues
From: Linus Torvalds (torvalds_at_osdl.org)
Date: 01/25/05
- Previous message: Paul E. McKenney: "Re: make flock_lock_file_wait static"
- In reply to: John Richard Moser: "Re: thoughts on kernel security issues"
- Next in thread: John Richard Moser: "Re: thoughts on kernel security issues"
- Reply: John Richard Moser: "Re: thoughts on kernel security issues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 25 Jan 2005 11:05:00 -0800 (PST) To: John Richard Moser <nigelenki@comcast.net>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Paul E. McKenney: "Re: make flock_lock_file_wait static"
- In reply to: John Richard Moser: "Re: thoughts on kernel security issues"
- Next in thread: John Richard Moser: "Re: thoughts on kernel security issues"
- Reply: John Richard Moser: "Re: thoughts on kernel security issues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
