Re: http://www.debian.org/security/2006/dsa-1184 - should I recompile?




Michael Heiming wrote:
In comp.os.linux.security Josh Diakun <joshd@xxxxxxxx>:
Michael Heiming wrote:
In comp.os.linux.security Josh Diakun <joshd@xxxxxxxx>:
You might want to refer to this posting:

Whatever you are replying to?

Well considering I was the first poster replying to this thread, could
the simple answer be ....that.... Im replying to the original post?

If you had ever used a real nntp reader you would know that I
can't see the OP anymore if I read your post or enter 'r' to
reply. There is no such thing anymore, just your answer and any
text you quoted...

From a person that relies on the simplicity of package managers, Im
surprised you have the patience to use a "real nntp reader". I'll be
sure from now on to use ' tin ' before posting to this group to know
that Im truely accepted :)


http://www.mail-archive.com/debian-security@xxxxxxxxxxxxxxxx/msg32842.html

and upgrade accordingly. 'default' kernel's from various
distribution's usually have the majority of option's enabled, so after
any install you should usually go ahead and re-configure the kernel
according to your system spec's, not only from a security standpoint
but also it'll help with system optimization.

Which is just a waste of time and adds unneeded complexity for
most new users. One should be fine just applying all vendor
updates through the distro provided tools.

APT HOWTO:

http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html

Or using the GUI version (Synaptic):

http://www.nongnu.org/synaptic/

Optimizations through self compiled kernels are usually quite
minimal and mostly not really worth the effort on some desktop.
Of course a good idea for learning purposes.

And thats exactley what it should be geared at, learning. Look at the

Great, then go ahead.

turnover time from when a vulnerability is released to when a patch is
created, and then built by independant package maintainers, propagated
to the community and sources updated. It takes less than a day to
learn how to build your own kernel, how to keep it patched and
up-to-date, in the long run this is a lot better than unpatched systems
running around out there dependant on people knowing how to use APT.
What if this user is to move away from Debian to another distro? The
general knowledge he gained from learning how to build his own kernel
and optimize his system (thus reducing bloat) can be carried over
easily.

Whatever bloat you are talking about? No such thing if your
kernel is highly modularized.

Look at the space now required by kernel configurations due to excess
code, modules, and so forth (bloat). The majority of home machines
(especially workplace desktops) do not need each module that is
compiled in, thus reducing the amount of space required. Reducing the
amount of modules, reduces the amount of system calls, reduces the
amount of security risk, plain and simple. Then there is no need for a
small time end-user to know what a kernel-based intrusion detection
system for detection of improper priveledge transitions is.



The latest distro update kernel should have all security fixes
back ported. Generally he should just go to a self compiled
version if some hw can only be supported by the latest kernel
from kernel.org. He needs to keep this kernel updated manually
while distro updates can be applied automatically.

Using automated system's is good and all, but for the lazy. It's only

Depends on the number of system you have to do it on, trust me
you'll like package managers if you just have enough systems.

If you have an excess number of machines, assuming you follow a
standard of specifications for the machines, you can just build your
own personal kernel then replicate it to each machine, thus reducing
the need for package managers/third party software.


two steps more to apply the current patch to update your kernel to the
most recent version as compared to waiting for some package maintainer
to update it and then propagate that update.

On how many systems? You might in addition just lose your support
contract if you install your own kernel...

See my comment above. 1. You would ahead of time know the guidelines
of the support contract ... 2. If you lose your support contract based
on a system-specific kernel configuration which should be easily
replicated to multiple machines (if that multiple machine network is
properly setup with the same system configuration throughout), then
that company does not have a grasp on a good support contract.


Patching the kernel:
http://www.linuxdocs.org/HOWTOs/Kernel-HOWTO-6.html

Glad you found it! ;-)

Good luck


As to you.

All the best,

Josh D.

.



Relevant Pages