Re: ABI-changing kernel security fixes for sarge
On Wed, 23 Mar 2005 23:10:18 +0100, Sven Luther wrote:
> On Wed, Mar 23, 2005 at 03:13:32PM -0500, Andres Salomon wrote:
>> OTOH, I have hardware that's already not supported by sarge (VIA video
>> chipset that's only supported by xorg). As much as the security team is
>> loathe to support multiple kernels, it does seem like having multiple
>> kernels in d-i is the safest way to support this sort of thing. We get
>> this for free in sarge, by having 2.4 and 2.6 kernels. In the future, it
>> might be worth having multiple 2.6 kernels, or decoupling drivers from
>> core kernel stuff (core kernel stuff is generally fairly easy to see
>> regressions in, so there's no need to have multiple version of that).
>
> What about building module specific packages, which divert the broken modules
> and replace them. This would even upto a point work for remote vulnerabilities
> limited to modules in d-i, as it would be easier to supply those .udebs prior
> to getting online or enabling the vulnerable module.
>
What constitutes a "broken" module? Or do you mean giving the admin
the ability to install multiple module packages in parallel? If modules
were decoupled from core, the ABI suddenly becomes even more important.
There are a lot of other issues to consider on the topic.
The main reason I like the idea of decoupling drivers is, I can see when
something in core is broken. It may take a lot of tracing through code,
but in the end, it makes sense (the notable exception being the arch/
subdir). With drivers, if something is broken, it tends to come down to
some hardware bug, or incorrect usage of a device; that sort of thing
needs people w/ hardware to test, vendor specs and errata, etc. As such,
it typically means regressions galore during large updates.
Core updates thus end up being safer, so doing them during, say, a stable
release is not something I would overly worry about. Driver updates are
another matter entirely.
> Do you have an idea whta proportion of security issues
involve modules,
> and not the core part as you put above ?
>
Well, I'd basically break up "core" by subdirectories; everything but the
drivers/ subdir would be in core. Most of the (publicized) security
issues are outside of drivers/; they've been in fs/, mm/, rarely in arch/,
etc. People seem to put more effort into security holes that affect
everyone, versus holes that only affect people w/ a specific card. That's
not to say there aren't holes in drivers; for example, I noticed the
following yesterday:
http://gkernel.bkbits.net:8080/netdev-2.6/cset@4240a807uDNeaAu3o43k2ejtLD6C-w
Looks like a potential security hole to me. Will it be publicized?
Probably not; it would be hard to exploit (I'm assuming someone would have
to be on the local network to work around the gateway ensuring frames
don't exceed the MTU), would only affect a small subset of Linux users,
and someone would actually have to go through the trouble of making sure
it actually *can* be exploited. There are plenty of these types of
fixes all over the drivers/ subdir; there certainly have been publicized
drivers/ holes (see Brad Spengler's advisories for moxa and so on), but
they're typically easy to spot and fix (integer overflows in ioctls, etc).
The holes in core generally get publicized, assigned CAN#s, etc; and
those are the ones we (debian, ubuntu, redhat, etc) fix. They also tend
to be a bit more complex; races in mmap, elf header mishandling, smbfs's
crackheaded code doing wacky stuff, and so on.
Reply to: