Re: thoughts on kernel security issues

[John Richard Moser <nigelenki@comcast.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Linus Torvalds wrote:
> 
> 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.
[...]

> 
>>>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.
> 

Not what I meant.

http://www.ubuntulinux.org/wiki/USNAnalysis

I'm more focused on this sort of security.  Finding and fixing bugs is
important, but protecting against the exploitation of certain classes of
bugs is also a major step forward.

> 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.
> 

Yeah I noticed.  I'm trying to grep through the grsecurity megapatch and
write an LSM clone (stackable already) based on those hooks to
reimplement GrSecurity, as an academic learning experience.  I try to
make something functional at each step (I did linking restrictions
first), but it's hard to find everything in that gargantuant thing
related to a specific feature :)

That being said, you should also consider (unless somebody forgot to
tell me something) that it takes two source trees to make a split-out
patch.  The author also has to chew down everything but the feature he
wants to split out.  I could probably log 10,000 man-hours splitting up
GrSecurity.  :)

> 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.

true. Very very true.

With things like Gr, there's like a million features.  Normally the
first step I take is "Disable it all".  If it still breaks, THEN THERE'S
A PROBLEM.  If it works, then the binary searching begins.

> 
> 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.
> 

Wasn't talking about bugfixes, see above.

> 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). 

Lots of work to split up a patch though.

> 
> See? 
> 
> 			Linus
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9qX3hDd4aOud5P8RAlMGAJ0cXEbY1QALk6EyfCNJDE26FdRYLQCdGOQB
799/tZxwWQkpv+a/eavf4EY=
=GQR6
-----END PGP SIGNATURE-----