[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ABI-changing kernel security fixes for sarge

On Thu, 24 Mar 2005 08:56:52 +0100, Sven Luther wrote:

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

I was with you up until the module-reload-in-postinst bit.  I think there
are enough broken refcounting modules that this won't work; plus, modules
that are actively in use (usb stuff that's mounted, nics, etc) won't be
able to be reloaded.

I also don't really think it's necessary; there has to be a better way to
allow an admin to revert back to an older version of a driver if the new
one is broken.

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

Yep.  I think Herbert had the right idea w/ his modularization patches;
they just needed to be in better shape (from upstream's perspective). 
It's probably worth spending time working w/ upstream to get all drivers
that we actually care about using the driver model, and dealing w/ module
issues nicely.

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

Jeff Bailey has been doing work w/ initramfs.  If we switch to this,
post-sarge, it will allow us to have much cleaner initialization, and more
intelligent, as well.  Instead of a mess of initrd shell scripts, and
magic initialization crud, we can have proper (small C) programs built
against klibc.  The setup that I've seen has been initializing networking
from within the initramfs image, and mounting / over nfs.  Rather nifty
stuff.  We could probably have a proper initialization via modules, where
the proper fbdev modules get loaded first, followed by the rest of the
initialization; without dealing w/ the initrd mess.  Something to
consider.  We'll have to play w/ it some more.

Reply to: