Re: thoughts on kernel security issues

[Marek Habersack <grendel@caudium.net>]

[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

On Thu, Jan 13, 2005 at 03:36:33PM +0000, Alan Cox scribbled:
> On Iau, 2005-01-13 at 03:53, Marek Habersack wrote:
> > That might be, but note one thing: not everybody runs vendor kernels (for various
> > reasons). Now see what happens when the super-secret vulnerability (with
> > vendor fixes) is described in an advisory. A person managing a park of machines 
> > (let's say 100) with custom, non-vendor, kernels suddenly finds out that they 
> > have a buggy kernel and 100 machines to upgrade while the exploit and the
> 
> Those running 2.4 non-vendor kernels are just fine because Marcelo
> chooses to work with vendor-sec while Linus chooses not to. I choose to
> work with vendor-sec so generally the -ac tree is also fairly prompt on
> fixing things. 
That's fine, but if one isn't on vendor-sec, they are still out in the cold
until the vulnerability with an embargo is announced - at which point all
the vendors are ready, but those with non-vendor kernels are in for an
unpleasant surprise. And as for 2.4, yes, Marcelo does a good job applying
the fixes asap, but that's not helping. If one runs (as I wrote) a kernel
with custom code inside, tux and, say, grsecurity - and it's not the latest
2.4 kernel - he still needs to backport the fixes and make sure they work
fine with is custom code, all that in a great hurry.  Somebody suggested
here that perhaps there could be a version of a security fix released for
X past kernel versions (2? 3?) if it doesn't apply cleanly to them. That
would be a great help along with earlier notification of a problem - not in
the way it is done with vendor-sec where you have to wear a pointy hat and
a beard to be accepted as a member. It's not that I'm whining or bitching,
hell no, I just think it would be more fair if everybody was treated the
same - vendors, non-vendors, bad guys, all alike.

> Given that base 2.6 kernels are shipped by Linus with known unfixed
> security holes anyone trying to use them really should be doing some
> careful thinking. In truth no 2.6 released kernel is suitable for
> anything but beta testing until you add a few patches anyway. 
> 
> 2.6.9 for example went out with known holes and broken AX.25 (known) 
> 2.6.10 went out with the known holes mostly fixed but memory corrupting
> bugs, AX.25 still broken and the wrong fix applied for the smb holes so
> SMB doesn't work on it
> 
> I still think the 2.6 model works well because its making very good
> progress and then others are doing testing and quality management on it.
> Linus is doing the stuff he is good at and other people are doing the
> stuff he doesn't.
> 
> That change of model changes the security model too however.
yes, definitely. IMHO, it enforces prompt and open security advisory/patch
releases, just as Linus proposed (with the limited embargo). Of course, one
can just take a released vendor kernel, patch it with their custom code and
compile the way they see it fit, but it's not in any way faster or better
than backporting the fixes to your own kernel.

regards,

marek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]