Re: Maintaining kernel source in sarge
On Fri, May 23, 2003 at 09:20:28PM +1000, Herbert Xu wrote:
> So unless someone can come up with a solution to this problem,
> we will have to live with multiple Debian source packages for now.
>
> This does make security fixes more difficult than it would be otherwise,
> however, I do not think it is unsurmountable given enough cooperation
> from the people involved.
I think that we can live with multiple source packages given a little bit of
infrastructure which more closely follows the way that kernel development
happens. We need to be able to introduce specific patches to all of our
kernels while minimizing the possibility of errors. Errors include breaking
kernel builds, breaking module packages, missing some kernel packages and
patches, etc. We also need to consider users who need to build their own
kernels.
> Here is my rough idea as to how it can work:
>
> 1. The architectures should be treated as independent packages.
By 'independent packages', do you mean that we should have separate
kernel-source source packages for each architecture? This would seem to be
a step backward.
> We should not be shy of releasing DSAs for some architectures before
> others. Since we cannot assume that all architectures are at the same
> version, some will inevitably take longer to fix due to the back-porting
> involved.
This is already the case. However, look at the mess which results: s390
and mips have integrated one of the ptrace patches into their respective
kernel-patch packages (DSA-276 and DSA-270). Now, how are we going to fix
i386? If we integrate the patch into kernel-source-2.4.17 or
kernel-source-2.4.19, then s390 and mips are now broken because they will
conflict.
> 2. We should be more liberal about adding new kernels to the stable
> archive and getting rid of old ones.
>
> The main advantage to this is in fact security. It is routine for small
> security fixes to enter a stable kernel unannounced. For instance,
> between 2.4.18 and 2.4.19, dozens of unannounced small security which only
> affect specific drivers were fixed. It also minimises any back-porting
> that has to be done when a security alert is raised.
I believe that we should not do anything to encourage this kind of
irresponsible behaviour. If an upstream is not willing to share information
about security fixes with us, we should not reward them by doing extra
integration work to try to push a new upstream release into stable.
What benefit is there in not announcing these problems? Security through
obscurity? How can we inform our users of their exposure when we are not
informed ourselves about security problems?
> The disadvantage is of course the potential to break existing systems.
> However, I believe this can be minimised through careful management and
> thorough testing. It is also mitigated by the fact that we allow multiple
> kernels to be installed simultaneously so it is easy to roll back.
>
> In fact, due to the use of modules, it is often impossible to make
> security fixes which are module ABI compatible with previous kernels. For
> example, the last two security holes (ptrace and net hash) both changed
> the modules ABI.
It is infortunate if this must sometimes happen, but hopefully it is an
exception, and in those cases we will need to rebuild modules and provide
for both kernel images to be installed at once.
I don't see why the ptrace fix necessitated a change in the module ABI
however, only that it was implemented that way upstream.
> Let me make it a bit more concrete as to what we can do about woody
> right now.
Yes, on that note: could you send any separate patches that you have for
these issues to team@security.debian.org?
- CAN-2003-0001: etherleak
- CAN-2003-0127: ptrace
- CAN-2003-0244: ip route cache hash
- CAN-2003-0246: ioperm issue
- CAN-2002-1380: mmap() on /proc/pid/mem
- CVE-2002-0429: lcall7 DoS
> Problem: Too many kernel-source packages.
>
> This is caused in part by gratuitous kernel-patch dependencies.
> Kernel-patch packages should *never* depend on a kernel-source
> package since the user can always use a kernel tar ball.
Here is a quick list for unstable:
mizar:[...deb/notmine/security/kernel] apt-cache dumpavail | grep-dctrl -nsPackage -FDepends kernel-source-
kernel-patch-2.2.20-powerpc
kernel-patch-2.4.19-powerpc
kernel-patch-2.4.20-hppa
kernel-patch-2.4.20-ia64
kernel-patch-2.4.20-powerpc
Shall I file bugs for these so that they can be fixed for sarge?
> Solution: Remove offending kernel-patch packages and kernel-source
> packages. Users of those kernel-source packages should be encouraged to
> upgrade to a later version. I'd recommend that we keep 2.4.18 and inject
> 2.4.19/2.4.20 as soon as possible. All architectures have kernel images
> in either stable or proposed-updates that is at least 2.4.18 or higher.
Removing kernel-patch package from stable does not help users who are
running kernels built from them, and this is not the least of the problems,
either. Linux 2.4 does not exactly have a clean record when it comes to
compatibility. What happens when some other package in woody breaks as a
result of blindly upgrading to a new kernel release? Do we then work to fix
that package, and then retest that packages which depend on it still work?
What if the package which breaks is, for example, glibc? It would not be
the first time.
Pushing a new kernel release is essentially punting to the user, forcing
them to decide between old bugs and new bugs.
--
- mdz
Reply to: