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

Security Supporting Debian Kernels in Sarge



We need to improve our kernel maintenance or it will be impossible to
support the Linux kernel security-wise in the future.  We = Security
Team at the moment.

Some of you may have noticed that I'm struggling again (or rather
still) with kernel updates for woody.  Even though this update went a
lot better than the last one, it is still not yet finished for all
architectures.

In woody there are currently:

  8 "native" kernel source packages (4x 2.2 and 4x 2.4)
 28 kernel image/patch source packages
  3 kernel image source packages including the full source

Just to give you an impression of the sheer amount of source packages
that need to be taken care of for a security update in the Linux
kernel, here's a list of the packages I know of and I am working
on/with.

   KV kernel-source 2.2.10
   KV kernel-source 2.2.19
   KV kernel-source 2.2.20
   KV kernel-source 2.2.22
   KV kernel-source 2.4.16
   KV kernel-source 2.4.17
   KV kernel-source 2.4.18
   KV kernel-source 2.4.19

      Source: kernel-image-2.2.22-alpha
      Source: kernel-image-2.4.18-alpha
      Source: kernel-image-2.2.19-netwinder
      Source: kernel-image-2.2.19-riscpc
      Source: kernel-image-2.4.16-lart
      Source: kernel-image-2.4.16-netwinder
      Source: kernel-image-2.4.16-riscpc
      Source: kernel-patch-2.4.16-arm
      Source: kernel-image-2.4.17-hppa
      Source: kernel-image-2.4.18-hppa
      Source: kernel-image-2.2.20-i386
      Source: kernel-image-2.2.20-reiserfs-i386
      Source: kernel-image-2.4.18-i386
      Source: kernel-image-2.4.18-i386bf
      Source: kernel-image-2.4.17-ia64
      Source: kernel-image-2.2.20-amiga
      Source: kernel-image-2.2.20-atari
      Source: kernel-image-2.2.20-bvme6000
      Source: kernel-image-2.2.20-mac
      Source: kernel-image-2.2.20-mvme147
      Source: kernel-image-2.2.20-mvme16x
      Source: kernel-patch-2.4.17-mips
      Source: kernel-patch-2.4.19-mips
      Source: kernel-image-2.2.10-powerpc-apus
      Source: kernel-image-2.2.20-powerpc
      Source: kernel-patch-2.4.17-apus
      Source: kernel-patch-2.4.18-powerpc
      Source: kernel-image-2.4.17-s390
      Source: kernel-patch-2.4.17-s390
      Source: kernel-image-sparc-2.2
      Source: kernel-image-sparc-2.4

To make it worse the source packages went rather out of sync with
regards to security related updates.  For the most important ones,
they are in sync again, but it's a pita to maintain.

It was even worse than this since several kernel packages did not even
built anymore on woody, for various reasons.  For some the respective
kernel-source package was removed, for others the code wasn't
compatible with the compiler anymore.  Don't ask me why.

I'm still not done with the CAN-2004-0077 (mremap) update and still
working on the CAN-2004-0109 (iso9660) update.

However, after fighting for months on an update for CAN-2004-0077 for
all architectures and all kernels, it was a lot easier to provide
updates for the CAN-2004-0109 vulnerability.

In order to be able to provide security updates for the kernel in
sarge certain rules need to apply.  Otherwise we will not be able to
provide updates properly.  We've already done a rather poor job in the
past, and the situation in sarge/sid is not looking promising.

  1. The number of different kernel versions must not increase!

  2. It is insane to expect us to support three main kernel lines
     (2.2, 2.4 *and* 2.6).

  3. The kernel source may only be provided by kernel-source packages
     that be maintained by the security team from the beginning of the
     freeze process.

     This implies that no kernel-patch/kernel-image may contain the
     full source.  I've been told that this is the case already.

  4. When sarge starts to go into freeze, the existing kernel packages
     have to be reduced to a minimum that we have to support.  It is
     not acceptable to have several kernel images per architecture
     when less would be sufficient to support all sub-architectures
     that we want to support.

  5. When sarge enter the freeze status, kernel patch/image
     maintainers should investigate whether the build dependencies of
     these packages are still fulfilled within sarge.

  6. When sarge enters its freeze status, kernel patch/image
     maintainers should re-compile these packages with the current
     tools in sarge in order to find out if the packages still
     compile.  If they don't, they should update the patch/image
     packages.

  7. It would be very helpful if kernel modules maintainers would
     inform me (us?) about which kernel modules packages require which
     kernel versions, so that we can provide updated modules if we
     need to.  This is very important for pcmcia modules so that
     notebook users won't lose their network connectivity with a
     kernel upgrade.

  8. Of course, the modules packages need to have their build
     dependencies fulfilled in sarge and compile as well.

  9. If you fix security vulnerabilities in packages in unstable or
     testing please mention the relevant CVE ID[1] in the changelog so
     the security team gets an easier chance to find out whether a
     package has fixed a certain bug or not.

At the moment we have 10 kernel source packages in sarge, which is
already two more than in woody, and at lest one source package is
missing (leading to an FTBFS for at least one kernel image package).

This is too much!

kernel-source-2.2.25  testing   2.2.25-3    all source

kernel-source-2.4.19  testing   2.4.19-11   all source
kernel-source-2.4.20  testing   2.4.20-14   all source
kernel-source-2.4.21  testing   2.4.21-8    all source
kernel-source-2.4.22  testing   2.4.22-7    all source
kernel-source-2.4.24  testing   2.4.24-3    all source
kernel-source-2.4.25  testing   2.4.25-1    all source

kernel-source-2.6.3   testing   2.6.3-2     all source
kernel-source-2.6.4   testing   2.6.4-1     all source
kernel-source-2.6.5   testing   2.6.5-1     all source

There are also 31 kernel-image packages for various architectures and
versions.  This is too much!

kernel-image-2.2.10-powerpc-apus  testing   2.2.10-13   source
kernel-image-2.2.25-amiga         testing   2.2.25-4    source
kernel-image-2.2.25-atari         testing   2.2.25-4    source
kernel-image-2.2.25-bvme6000      testing   2.2.25-4    source
kernel-image-2.2.25-mac           testing   2.2.25-4    source
kernel-image-2.2.25-mvme147       testing   2.2.25-4    source
kernel-image-2.2.25-mvme16x       testing   2.2.25-4    source
kernel-image-2.4.17-s390          testing   2.4.17-3    source
kernel-image-2.4.19-arm           testing   2.4.19-6    source
kernel-image-2.4.21-1-i386        testing   2.4.21-5    source
kernel-image-2.4.21-s390          testing   2.4.21-2    source
kernel-image-2.4.24-amiga         testing   2.4.24-1    source
kernel-image-2.4.24-i386          testing   2.4.24-3    source
kernel-image-2.4.25-alpha         testing   2.4.25-1    source
kernel-image-2.4.25-amiga         testing   2.4.25-1    source
kernel-image-2.4.25-arm           testing   2.4.25-3    source
kernel-image-2.4.25-atari         testing   2.4.25-1    source
kernel-image-2.4.25-bvme6000      testing   2.4.25-1    source
kernel-image-2.4.25-hppa          testing   2.4.25-2    source
kernel-image-2.4.25-i386          testing   2.4.25-1    source
kernel-image-2.4.25-ia64          testing   2.4.25-4    source
kernel-image-2.4.25-mac           testing   2.4.25-1    source
kernel-image-2.4.25-mvme147       testing   2.4.25-1    source
kernel-image-2.4.25-mvme16x       testing   2.4.25-1    source
kernel-image-2.6.3-alpha          testing   2.6.3-2     source
kernel-image-2.6.3-i386           testing   2.6.3-2     source
kernel-image-2.6.3-ia64           testing   2.6.3-3     source
kernel-image-2.6.4-ia64           testing   2.6.4-1     source
kernel-image-sparc-2.2            testing   9           source
kernel-image-sparc-2.4            testing   35          source
kernel-image-speakup-i386         testing   2.4.24-1    source

I haven't checked whether build dependencies are still fulfilled but
looking at kernel-image-2.2.10-powerpc-apus and
kernel-image-2.4.17-s390 I have some doubts they are.

There are also 62 kernel-patch packages of which at least the
following 17 seem to produce kernel-image packages:

kernel-patch-2.4.19-mips        testing   2.4.19-0.020911.9    source
kernel-patch-2.4.19-s390        testing   0.0.20021125-1       source
kernel-patch-2.4.20-apus        testing   2.4.20-1             source
kernel-patch-2.4.20-hppa        testing   pa35.3               source
kernel-patch-2.4.21-hppa        testing   pa7.3                source
kernel-patch-2.4.21-s390        testing   2.4.21.10-4          source
kernel-patch-2.4.22-mips        testing   2.4.22-0.030928.5    source
kernel-patch-2.4.22-powerpc     testing   2.4.22-13            source
kernel-patch-2.4.25-apus        testing   2.4.25-2             source
kernel-patch-2.4.25-arm         testing   20040316             source
kernel-patch-2.4.25-hppa        testing   2.4.25-pa1           source
kernel-patch-2.4.25-ia64        testing   2.4.25-2             source
kernel-patch-2.4.25-m68k        testing   2.4.25-1             source
kernel-patch-2.4.25-powerpc     testing   2.4.25-4             source
kernel-patch-2.4.25-s390        testing   2.4.25-1             source
kernel-patch-2.6.3-ia64         testing   2.6.3-2              source
kernel-patch-2.6.4-ia64         testing   2.6.4-1              source

This makes it 10 kernel source packages, with at least two missing and
48 kernel image/patch packages that need to be taken care of in case
of a security update.

Expecting the security team to support these is just TOTALLY INSANE.

If you want us to support the Linux kernel once sarge is released,
please help us keep the number of different kernels small and
buildable at least.  Keeping them maintainable would be even better.


To quote a member of the security team:

Joey: in sarge we have 11 kernel-source packages
Joey: *ELEVEN*
We will release with 11 kernel-source packages over my dead, decaying body.
                -- Matt Zimmerman

[1] CVE IDs are unique identifiers for vulnerabilities in software.
    <http://www.debian.org/security/cve-compatibility>  You can search
    for an id on <http://cve.mitre.org/cve/> on your own.  You can
    also contact the security team if they know of an idea for a
    certain bug as well.  We may have seen it somewhere already.

Regards,

	Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.



Reply to: