[SOLVED] linux kernel: 64-bit Compatibility Mode vulns (local root exploit)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Interesting choice and definitely not one I would have chosen. Especially in current where stability (in the non-changing sense of the word) isn't necessary.
I, for one, am glad to install the new, patched kernel. It fixes a known vulnerability. That's good.
Quote:
I'm more convinced than ever that if you're going to run a secure slackware box, you absolutely have to run your own custom kernel build and keep up to date with a branch that is still maintained upstream.
The linux kernel devs are well known for their policy of treating security bugs just as any other bug and not highlighting them specifically as security concerns. If all Pat has done is apply the patches necessary to fix these latest 64-to-32bit-syscall-compat holes then there's bound to be other issues still lurking in his patched 33.4 that have been silently fixed upstream in later kernel branches.
Why are they silently fixed upstream? Shouldn't that stuff be visible in a changelog somewhere?
Quote:
The bigger distros (especially the commercial ones) have their own kernel dev teams that can follow these things in detail and back-port security fixes they identify to their own 'stable' series kernels. I doubt Pat either has the time or the in-depth kernel knowledge necessary to do that.
This sounds like a perfect volunteer opportunity for somebody to build a slackkernels.org web site hosting custom, backported stable kernels. Then, after a few years of being useful, the site could become an official unofficial Slackware site mentioned in Slackware 15's RELEASE_NOTES.
I, Why are they silently fixed upstream? Shouldn't that stuff be visible in a changelog somewhere?
If I remember rightly, Linus' argument is that security bugs are just bugs no different than any other bugs and the kernel devs will treat them just like other bugs, with no special treatment. The rationale is that by highlighting them as 'security' bugs, they're actually helping the script-kiddies and exploit writers to identify the holes. However, the opposite side of the coin is that by not highlighting them they also make it difficult for distro maintainers to identify the necessary patches.
That's fair enough so long as everyone is running the latest upstream kernel, but as we see here, distros tend to hang back for 'stability' reasons. The next question is obviously why do the distros hang back then, and the simple answer to that is that kernel.org 'stable' kernels aren't always that stable (in either sense of the word).
And that brings us back to my view on the subject.
Unless you're willing/able to put the effort into having your own in-house kernel team who can maintain their own kernel, then in order to remain secure you either need to follow the latest long term support kernel branch (currently 2.6.32) or you follow the leading edge (currently 2.6.35). I honestly don't think any other choice makes sense with the way kernel development is done upstream.
Slackware currently finds itself in the awkward situation of running a unmaintained branch of the kernel 2.6.33. It's simply not a good situation to be in, and as I've said before IMO it was a mistake not to go with 2.6.32 when Slackware 13.1 was released.
If I were Pat, which of course I'm not. I would provide 2 kernel choices. The latest of whatever the current kernel.org long-term support branch is, and the latest of whatever the most recent stable branch is.
Obviously, the situation is easily rectified by building your own kernel at whatever version you feel comfortable with, but that's something novices might find a little intimidating.
Well, that's how I see things anyway. Everyone else is of course free to disagree.
If I were Pat, which of course I'm not. I would provide 2 kernel choices. The latest of whatever the current kernel.org long-term support branch is, and the latest of whatever the most recent stable branch is.
Obviously, the situation is easily rectified by building your own kernel at whatever version you feel comfortable with, but that's something novices might find a little intimidating.
Well, that's how I see things anyway. Everyone else is of course free to disagree.
I really like your suggestion for 2 kernel choices: it actually sounds like a great one for any distribution.
As for intimidation, I was pleasantly surprised at how easy making the kernel was (I haven't done it in a few years).
Code:
# check out the stable branch from kernel.org
cd /usr/src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.35.y.git
mv linux-2.6.35.y linux-stable
# OR, if you cloned before, pull the head of the branch
cd /usr/src/linux-stable
git pull
# import a config file, unless you want to manually configure
cd /usr/src/linux-stable
cp /boot/config-huge-old-version ./.config
make oldconfig
make
su -
make modules_install
# your arch may vary:
cp ./arch/x86_64/boot/bzImage /boot/image_name
cd /boot
# the version should be, of course, the current one:
mkinitrd -o initrd_name -k 2.6.35.4
add to /etc/lilo.conf
Code:
image = /boot/image_name
initrd = /boot/initrd_name
# your device may differ:
root = /dev/sda1
label = slackware
At last,
Code:
lilo
sync
sync
init 6
Hmmm, may be I should write a scripty for this?
Last edited by qweasd; 09-22-2010 at 07:17 PM.
Reason: typo
I wrote a wrapper script to automate package builds of my kernels. I just type
VERSION=2.6.35.5 ./kernel.SlackBuild
and 5-10 minutes later kernel-generic, kernel-modules and kernel-firmware packages are sitting in /tmp.
It's a bit rough and ready and it could be done a lot better (using the make O= approach to the build), and it could definitely do with a little extra error checking but it's been serving me well so far.
kernel.SlackBuild:
Code:
#!/bin/sh
#
# Build Slackware kernel packages
#
# Usage:
# "VERSION=2.6.33.nn ./kernel.SlackBuild"
# where nn is the patch number.
#
VERSION=${VERSION:-2.6.33}
MAJOR_V=$( echo $VERSION | cut -f 1-3 -d '.' )
MINOR_V=$( echo $VERSION | cut -f 4 -d '.' )
if [ -n "$CONFIG" ] ; then
CONFIG=$(readlink -f "$CONFIG") # Cannonicalise
fi
# BASEDIR: Directory containing this script.
BASEDIR=$(readlink -f $(dirname $0))
# DISTFILES: Directory containing kernel source tarballs
# and patch files.
DISTFILES=${DISTFILES:-${BASEDIR}/distfiles}
DISTFILES=$(readlink -f "$DISTFILES") # Cannonicalise
# FTP_SITE: Site to pull kernel source and patch files from if no
# local copy is found.
FTP_SITE="ftp://ftp.eu.kernel.org/pub/linux/kernel/v2.6"
# Test for existence of source distribution files and get them if necessary
#
cd $DISTFILES || exit 1
test -f "linux-${MAJOR_V}.tar.bz2" || \
lftp -c "mget $FTP_SITE/linux-$MAJOR_V.tar.bz2*"
gpg --verify "$DISTFILES/linux-$MAJOR_V.tar.bz2.sign" || exit 1
if [ "$MINOR_V" != "" ] ; then
test -f "patch-${VERSION}.bz2" || \
lftp -c "mget $FTP_SITE/patch-$VERSION.bz2*"
gpg --verify "$DISTFILES/patch-$VERSION.bz2.sign" || exit 1
fi
# Clear Source tree
#
if [ "$MINOR_V" != "" ] ; then
rm -rf "/usr/src/linux-${VERSION}"
fi
rm -rf "/usr/src/linux-${MAJOR_V}"
# Unpack Kernel source
#
cd /usr/src || exit 1
tar -jxf "$DISTFILES/linux-${MAJOR_V}.tar.bz2" || exit 1
if [ "$MINOR_V" != "" ] ; then
mv "linux-${MAJOR_V}" "linux-${VERSION}" || exit 1
cd "linux-${VERSION}" || exit 1
bzip2 -dc "$DISTFILES/patch-${VERSION}.bz2" | patch -p1 || exit 1
fi
# Build Kernel
#
cd "/usr/src/linux-${VERSION}" || exit 1
make mrproper
if [ "$CONFIG" != "" ] ; then
cat "$CONFIG" > .config || exit 1
else
zcat /proc/config.gz > .config || exit 1
fi
make oldconfig
make -j3 bzImage modules || exit 1
make modules_install || exit 1
# Build kernel packages
#
export VERSION # make VERSION available to following slackbuild scripts
cd ${BASEDIR}/kernel-generic && \
echo 'continue' | ./kernel-generic.SlackBuild || exit 1
cd ${BASEDIR}/kernel-modules && \
./kernel-modules.SlackBuild || exit 1
cd ${BASEDIR}/kernel-firmware && \
./kernel-firmware.SlackBuild || exit 1
## end.
The 3 Slackbuild directories at the bottom are direct lifts from the slackware sources. (One of them I had to change to use $VERSION correctly because it had the version number hard coded in it - can't remember which one)
That's a pretty cool script. Given that it uses the oldconfig, it seems best for updating the stock Slackware kernels. Is there a way to set up the script to use the interactive menu config and then continue on to make the packages?
Yep if you throw a make menuconfig in there then it'll give you the chance to change things when it runs.
I wrote it because I found that I was typing the same commands each time a new kernel came out, I never really intended it for a wider audience, so if you decide to use it be a little wary of it.
I normally do the menuconfig manually outside of the script and copy the config file into my configs subdirectory and then use the CONFIG= variable
FYI, the directory structure I run it in looks like this:
Just curious... any benefits to packaging up the kernel instead of manually copying the new kernel's bits to their designated locations? I have to admit, that script is pretty neat!
The way Pat has written his kernel.Slackbuilds, which my script wraps around, he basically puts all the bits in place and then packages them up from their installed location (well, for modules anyway) so the only advantage you have in using the packages is that you end up with some packages laying around, and of course, all the files get registered in /var/log/packages so it's nice and easy to remove them (not that it's hard to remove them if you don't).
The packages come in handy if you ever want to install on more than one box or need to reinstall though.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
