Re: kernels exploitable

On Tue, 23 Jun 2015, Dan-Simon Myrland wrote:

> I thought they did.. but It seems like they are still running the
> kernel it shipped with in 2012. In any case, running an old distro
> is not optimal if you are concerned with security. Perhaps it is
> time for an upgrade (or better yet, wait a little while for the new
> Slackware release to hit the mirrors)?
>
> It is very easy to manualy install a new kernel in Slackware though
> (but not recommended mind you..). Simply:
>
> * Download the latest kernel, extract it
> wget https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.0.6.tar.gz
> cd /usr/src
> tar -zxvf /path-to-kernel/linux-4.0.6.tar.gz
> rm linux
> ln -s linux-4.0.6 linux
>
> * Copy the running Slackware kernel configuration
> zcat /proc/config.gz > /usr/src/linux/.config

in this case you'll loose at least NAT support in iptables, and it seems 
somethig other random features that have changed it's option names or 
dependency option name

>
> * Compile kernel (use old config as a starting point)
> cd linux
> make oldconfig
> make xconfig
> make all
>
> * Install new kernel
> cp arch/x86/boot/bzImage /boot/vmlinuz-custom-4.0.6
> cp System.map /boot/System.map-custom-4.0.6
> cp .config /boot/config-custom-4.0.6
> cd /boot
> rm System.map
> ln -s System.map-custom-4.0.6 System.map
>
> * Edit your bootloader
> Open /etc/lilo.conf, you should see something like this towards the end:
>
> image = /boot/vmlinuz
> root = /dev/sda1
> label = linux
> read-only # Non-UMSDOS filesystems should be mounted read-only for checking
>
> Now add the following below this:
>
> image = /boot/vmlinux-custom-4.0.6
> root = /dev/sda1
> label = newkernel
> read-only
>
> run /sbin/lilo to apply this new entry
>
> * Test your new kernel
> Reboot, and choose 'newkernel' instead of the default 'linux', if everything
> works chenge the default = linux to default = newkernel in /etc/lilo.conf
> and run /sbin/lilo. Congratulations, you have now the very latest kernel!
>
> For more info on this prosess read:
> http://docs.slackware.com/howtos:slackware_admin:kernelbuilding
>
>

Yes, cherrypick bugfixes from upstream implies not only tracking of 
changes, but reviewing the code itself not to break existing stuff with 
newcomming patches and this is resource (work time) consuming task.

<offtopic mode on>
Slackware have kernel-like team management but team itself is not that 
large. And due to very conservative approach to system design and idea 
that software should be as vanilla as possible, and whole distribution 
_must_ be as simple as it really can be - there not too much maintainers 
that support older releases of Slackware.

Thinking of tendency that complexity of software increases with 
development process progressing, Slackware maintainers should think of 
increasing of amount of active team members. But this is separate topic to 
discuss :)
<offtopic mode off>


> On 06/23/2015 01:17 AM, Nick Edwards wrote:
>>  It just dawned upon me that 14.0 is still running its default kernel.
>>
>>  Does slackware not update kernels in its distros anymore, myriad of
>>  bugs fixed in 3.2 and we are still on 3.2.9  when its actually at
>>  3.2.69 - Id hate to think of how rootable these 14.0 pc's are.
>>
>>  ! We run custom kernels on servers (3.16) but policy on desktops are
>>  to stay only using slackware released software/updates.
>>
>>  cant believe after all these years i've not noticed  how risky we are
>>  with our kernels (maybe because my job involved  servers not office -
>>  until now), every other distro updates them, but ours it seems.. thats
>>  scary!
>>
>>  _______________________________________________
>>  slackware mailing list
>>  [email protected]
>>  https://mailman.lug.org.uk/mailman/listinfo/slackware
>
>
> _______________________________________________
> slackware mailing list
> [email protected]
> https://mailman.lug.org.uk/mailman/listinfo/slackware
>
>

-- 
eleksir