Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
After seeing the kernel patch thread, and the offer made in there, I felt I couldn't pass up on asking a few questions. Previously, I have downloaded the recent grsecurity patch and its compatible kernel (grsecurity-1.9.6-2.4.19.patch.gz and linux-2.4.19.tar.gz, respectively). I followed the installation instructions found in the documentation at http://grsecurity.net/gracldoc.htm and everything looked ok. When I ran make xconfig, the following occurred:
root@slack:/usr/src/linux# make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make: Entering directory `/usr/src/linux-2.4.18/scripts'
cat header.tk >> ./kconfig.tk
./tkparse < ../arch/i386/config.in >> kconfig.tk
echo "set defaults \"arch/i386/defconfig\"" >> kconfig.tk
echo "set ARCH \"i386\"" >> kconfig.tk
cat tail.tk >> kconfig.tk
chmod 755 kconfig.tk
make: Leaving directory `/usr/src/linux-2.4.18/scripts'
wish -f scripts/kconfig.tk
Application initialization failed: no display name and no $DISPLAY environment variable
Error in startup script: invalid command name "button"
(file "scripts/kconfig.tk" line 51)
make: *** [xconfig] Error 1
I searched google for this and eventually found something about applying some extra code somewhere, but I don't feel that comfortable working with the kernel yet. So I ran make menuconfig and that loaded up fine. I didn't see any extra options implemented by grsecurity so I exited the kernel configuration without changing anything but saved the configuration. I proceeded to execute the remaining commands (make dep bzImage modules modules_install install) and change my boot loader information:
I then ran /sbin/lilo and successfully rebooted. Everything was ok until I went to ssh into the machine. It would not let me even put in a user name. Just kept denying access. I checked to make sure sshd was running, and it was. Flushed all the firewall rules (only running iptables). So what it comes down to is:
1. Was the grsecurity patch applied, and if so, where do I access it's configuration options for the kernel?
2. How do I resolve the errors I received from executing make xconfig?
3. Why am I now locked out even though I didn't make any changes to the kernel configuration when I was in make menuconfig?
To start with your most recent question, I applied the gzipped version as "gunzip -cd lq3.gz | patch -p0 -d /usr/src/linux" over a pristine kernel, if you want to verify that this works try using patch with "--dry-run" would show any errors. The rest of the kernel config/compile remains the same ofcourse.
1. Grsecurity's features are the last ones in the config. Applying the kernel patch doesn't automagically enable them unless you copy over a .config which already has been used to enable Grsecurity-1.9.6. If you did enable it's sysctl option you will find them options under /proc/sys/kernel/grsecurity. Everything there *except* acl is tweakable.
Sysctl options can be set automated by using sysctl or echoing a set of variables. Using "sysctl -e -p /etc/grsec.conf", the grsec.conf entries would look like
"kernel.grsecurity.restrict_ksyms =0" (w/o quotes).
3. If you didn't make any changes to the kernel options you already had plus you didn't post the relevant Grsecurity options you enabled in the first place, I cannot determine why the error would lie with Grsecurity.
If you have sysctl turned on for it, have a look at if any socket_.* options are enabled.
These are available to help restrict creation of (any|client|server) sockets for local users.
I tried applying the patch as recommended, and ran into this:
root@slack:/usr/src# gunzip -cd 2.4.19-lq3.gz | patch -p0 -d /usr/src/linux --dry-run
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|diff -Nru linux-2.4.19/Documentation/Configure.help linux-2.4.19-lq/Documentation/Configure.help
|--- linux-2.4.19/Documentation/Configure.help Fri Aug 2 18:39:42 2002
|+++ linux-2.4.19-lq/Documentation/Configure.help Mon Sep 23 06:58:06 2002
File to patch:
This has happened to me once before (the first time I tried applying GRsecurity), but every time after that it had gone through a whole process and reported no errors. So I'm pretty uncertain about what needs to be done here.
This is some crazy stuff. Here is the listing of how it went down:
[list=1][*]Downloaded linux-2.4.19.tar.gz kernel[*]Downloaded 2.4.19-lq3.gz from Linux Questions[*]Checked md5sums[*]Executed the following commands:[/list=1]
root@slack:/usr/src/$ gunzip -cd 2.4.19-lq3.gz | patch -p0
root@slack:/usr/src/$ cd linux-2.4.19
root@slack:/usr/src/linux-2.4.19$ make xconfig
At this point make xconfig failed again as it had before.
root@slack:/usr/src/linux-2.4.19$ make menuconfig
The only section I edited was 'Grsecurity', and all I did was enable stack overflow protection. Nothing else.
root@slack:/usr/src/linux-2.4.19$ make dep bzImage modules module_install install
root@slack:/usr/src/linux-2.4.19$ cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.19
root@slack:/usr/src/linux-2.4.19$ cp System.map /boot/System.map-2.4.19
root@slack:/usr/src/linux-2.4.19$ vi /etc/lilo.conf
<made following changes>
image = /boot/vmlinuz-2.4.19
label = 2.4.19
root@slack:/usr/src/linux-2.4.19$ shutdown -r now
Everything looked normal in the reboot process. Everything loaded back up. I saw it successfully start the sshd again. One note is the frame buffer was now gone. It prompted me for login so I logged in as my regular user name, and this is what happened:
No directory, logging in with HOME=/
Last login ... on pts/0 from clax.
My /home directory is empty, and I am again remotely locked out (thank goodness for kvm). Now my status qualifies for completely lost + confused + frustrated. At this point I'm currently looking through google trying to find someone with similar experiences that solved the problem; but any advice, information, and resources you have would be appreciated.
welp,. you didn't change ANYTHING else on the default kernel .config ?
if you have /home on a seperate partition, it might be of an unsupported filesystem. this explains your lack of a framebuffer...
/ is mounted on /dev/hda2 while /home was mounted on /dev/hda7. I didn't think to check before my previous post, but the only partition that exists now is /dev/hda2, everything else is gone. /home was ext3 by the way, and I'm assuming that the data regarding the framebuffer was stored somewhere in there.
I could be like, missing something or misunderstanding stuff..
Nope, you seem to be correct in what you posted. I am the one who is misunderstanding and missing things
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
You will need to configure your new kernel to support what your old kernel did. Do you have an old .config you can use as a baseline? If not you will have to go through the options and make sure you add support for everything you use (such as ext3).