Re: Kernel upgrades = security upgrades - a possible solution?
On Tue, Sep 28, 1999 at 05:05:21PM -0500, Brian Servis wrote:
> *- On 28 Sep, Fraser Campbell wrote about "Re: Kernel upgrades = security upgrades"
> > Brian Servis wrote:
> >
> >> Notice that the version is part of the package name. Thus a
> >> kernel-image-2.0.34 and kernel-image-2.0.36 are two totally different
> >> packages as far as Debian is concerned, except that they both provide
> >> the virtual package kernel-image and that fact is not determined until
> >> it is being installed.
> >
> > Ok. To my way of thinking it should be called kernel-image_2.0.34,
> > kernel-image_2.0.36-3, etc. That way apt-get upgrade would grab updated
> > kernels for the user. IMO kernels are a very critical part of security and
> > that they should be upgradeable as part of the normal process.
> >
> > I realize the kernel is a very special piece of software but still see no
> > reason why it is treated differently from normal software. Perhaps the
>
> If kernel-images did not have the version in the package name then you
> could not have two different versions of the kernel installed at the
> same time. There are instances where having two different kernels is
> needed. Such as for development machines where code must be checked
> under various kernel versions. This is especially true for the case
> when a new stable kernel branch is released and not all programs are
> compatible with the newer kernel, such as was the case with 2.0.x and
> 2.2.x kernels.
>
>
> > upgrade process depends on the virtual package kernel-image which I don't
> > seem to have installed?
> >
>
> The Debian-policy best describes how virtual packages work:
>
> 2.3.5. Virtual packages
> -----------------------
>
> Sometimes, there are several packages doing more-or-less the same job.
> In this case, it's useful to define a _virtual package_ who's name
> describes the function the packages have. (The virtual packages just
> exist logically, not physically--that's why they are called
> _virtual_.) The packages with this particular function will then
> _provide_ the virtual package. Thus, any other package requiring that
> function can simply depend on the virtual package without having to
> specify all possible packages individually.
the way to solve the problem would be to create a package called e.g.
"secure-kernel", which would depend on the most secure "kernel-image-<ver>".
Then if the security team has newer kernel with security bugfixes, they
would make a new version of "secure-kernel" which would depend on the fixed
kernel.
any objections?
Marcin
--
--------------------------------
Marcin Owsiany
porridge@pandora.info.bielsko.pl
--------------------------------
Reply to: