Re: ABI-changing kernel security fixes for sarge
On Wed, Mar 23, 2005 at 11:53:45PM -0500, Andres Salomon wrote:
> 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.
Well, i was thinking about handling security issues in modules without needing
the full kernel rebuild.
You have the kernel as normal, and some infrastructure similar to the
non-free-modules one, where the affected kernel will not be rebuilt, but we
only generate a module package / .udeb that fixes said security hole, and
upload it to security.d.o, together with a meta-package
(kernel-security-modules or whatever) that depends on it and that will be
installed per default in sarge. This means that a apt-get upgrade with
security will pull in the new module, which will replace the actual module
with the diversion mechanism, and then in the postinst ensure that the module
gets unloaded and reloaded or whatever. Not sure about how this last mechanism
will actually work in the face of permanent modules and module in a dependency
chain where one part of the system depends on them.
But then, i have a feeling that mostly the security holes where not really in
modules but in some main part.
> 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.
Mmm, you are thinking driver/modules updates separated from the kernel here,
not security fixes.
> 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.
Ok. This seems to be material for etch though, and something we need to
lengthily discuss.
> > 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.
Ok. So that makes my own idea not so good, but i understand that building the
core part apart from the drivers may be possible, but may represent lot of
work.
Not all things under drivers are modularizable, and some of them are built in
the kernel (like fbdev drivers, or serial-ata console).
This joins something i have been interested in a long time for the
over-modular powerpc kernel. We have a problem with all the fbdev drivers.
They have to be builtin to get early console output, but we cannot buildin all
the fbdev drivers that are available.
My idea would be to have a mechanism for loading modules earlier, and move the
initrd initialization as early as possible, and load modules from there even
before we do stuff like serial console setup or framebuffer setup.
But this is probably something for etch too.
Friendly,
Sven LutherSo that makes my own idea not so good, but i understand that
building the core part apart from the drivers may be possible, but may
represent lot of work.
Not all things under drivers are modularizable, and some of them are built in
the kernel (like fbdev drivers, or serial-ata console).
This joins something i have been interested in a long time for the
over-modular powerpc kernel. We have a problem with all the fbdev drivers.
They have to be builtin to get early console output, but we cannot buildin all
the fbdev drivers that are available.
My idea would be to have a mechanism for loading modules earlier, and move the
initrd initialization as early as possible, and load modules from there even
before we do stuff like serial console setup or framebuffer setup.
But this is probably something for etch too. i will now post another thread
about the sarge kernel issues in this thread.
Friendly,
Sven Luther
Reply to: