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

Re: Will 2.4.20 Source be patched for the latest kernel vulnerability?

On Thu, Dec 04, 2003 at 07:54:03AM -0800, Karsten M. Self wrote:
> on Wed, Dec 03, 2003 at 04:57:29PM +0100, Adam ENDRODI (borso@vekoll.saturnus.vein.hu) wrote:
> > 
> > I tend to disagree.  The kernel is a versatile program, it can be
> > patched, configured and compiled in too many ways.  
> ...including many of which are wrong, broken, or suboptimal.
> I already count seven builds of the 2.4.20 kernel on x86 architecture,
> fitting specific needs of different specific kernel types as well as
> uni- and multi-processor systems.

I can't accept that the seven builds could come ahywhere close to
satisfy adequately the needs of 75% of the user base at least.
Perhaps there are actually more people who rely on the prebuilt
kernel packages but I'm sure a great deal of the installations
are a result of the lack of time, skills or motivation.

To illustrate my point, let us suppose you want a module-less
system.  This case all of the prebuilt binary packages suddenly
become useless.  What if you need a driver for thrid-party NIC
which conflicts with another in the vanilla tree?  What about
PaX + UML which you cannot apply to the same tree without
tinkering the source?

No doubt, many people, for they don't know any better, can survive
without the features I've outlined above, but it appears to me the
solution (of staying with dpkg -i kernel*) leads them to a
situation you've described in you reply: suboptimal.

> > To sum up, it's always great to have a chance to learn from
> > the more experienced, but I don't expect them to do my homework.
> > They are not supposed to.
> You're missing the point of collaborative development.
> For the individual, or group, which puts the effort into building a
> secure architecture, Debian offers distribution, bugtracking, QC, and
> release mechanisms which can prove highly useful.  In the specific case
> of kernel hardening, there's the question of how to package and
> structure things in a way that's useful across other axes of variance
> (arches, SMP/UP, server/workstation/desktop, etc.), but the task isn't
> impossible.

You've misunderstood what I tried to explain, I'm afraid.  I was
talking specially about the kernel, not the general consciousness
of the project.  I really appreciate the effort the Debian Developers
make to produce well-thought, accountable and cooperating packages that
cover the common expectations.

On the other hand, it's impossible for them to prepare for the
less common ones.  How come I've never been able to deploy any
web service (phpmyadmin, mailman, bugzilla, ...) via a simple
dpkg -i?  The packages place files under /var/www when I need
a different destination directory in a different layout and
with different owner/group/permissions; the packages put symlinks
and suid binaries here and there which I don't allow; the php
scripts are assumed to be interpreted by the mod_php module
that I refuse to load...

Little details of a system are subject to change and my
observation is that the more you customize the more likely
you'll end up in trouble.  Clearly, in my case with my little
changes I diverge from the Debian (and likely other) standards
more than the automatic install scripts could tolerate.

In a nutshell, I can hardly imagine a well-maintained system
without a fistful of customizations, and in my opinion, it's
easy to reach the point after which the standard Debian
packages cannot support your strategies.  And certainly,
the Debian developers are not to be blamed for the natural
limitations of their packages.

> Peace.



Am I a cleric?     | 1024D/37B8D989
Or maybe a sinner? | 954B 998A E5F5 BA2A 3622
Unbeliever?        | 82DD 54C2 843D 37B8 D989
Renegade?          | http://www.keyserver.net

Reply to: