grsecurity forums

Grsec test for kern 2.6.28.7 crashes on AMD dual proc a bit after ALSA and portmap start
(Using LUKS btw, and a config from previous 2.6.26.6 grsec)
(grsecurity-2.1.13-2.6.28.7-200902232153.patch is the test patch being used):

---[ end trace 0229ac2f1cd7c96d ]---

It didnt' even say kernel panic.
What do I do?
I'm sure the old linux kernel isn't secure (linux collects security expoits quickly) but I can't run the new one.

My grub menu.lst:

title Debian GNU/Linux, kernel 2.6.28.7
lock
root (hd0,0)
kernel /vmlinuz-2.6.28.7-grsec root=/dev/mapper/caethaver2-root ro quiet
initrd /initrd-2.6.28.7.img
savedefault

The computer is a 6 yrs old AMD dual proccessor computer.

Note I use ECC Ram and the only new option I used was the increased memory restrictions (the one where X11 wouldn't work at all with (this server doesn't need or load x11 ))

Is there any way this can be fixed? Is more information required? What information if so?
It seems to mount the filesystem fine, it just crashes a few seconds after doing so.

Did you try to start linux in a "single" mode to try and find out which process in the default runlevel causes a problem?

Just type the kernel at the prompt followed with "single" and you will start in single user mode (use your root-password to login). After you can find out the standard runlevel used and start all the items on after another using the standard scripts (like "/etc/init.d/alsa start") to find the failing process.

On the next run you could try starting without the crashing program. After booting up you can try to start that programm in a more verbose mode. Perhaps you could try to use tools like strace.

PS, I really am surprised you were able to use the 2.6.26.6-config in 2.6.28.7. For a smaller upgrade from 2.6.27.10 to 2.6.28.3 I found I needed to change a lot of options using "make oldconfig". More than I usually do in 1 upgrade. Also I needed to change a lot of options which potentially prevent a system from booting (which is why I took more time to upgrade my server as usual even after having tested the patch on a workstation).

PPS, why would you start ALSA on a server? I hope you do use NFS or another sunrpc service and therefore actually have some use for portmap, but you should also ask yourself why you want to start portmap.

Removing portmap (debian keeps reinstalling it periodically).
This is a "production" server so I can't reboot it all the time
I loaded the kern config in make menuconfig

Re-installing portmap is not basic Debian behaviour. My server does not do it, my workstations use NFS so uninstalling portmap is no option there.
Even if I am unable to de-install a programm I'd at least remove the link to the script in /etc/rc2.d. Why run a script if you don't use the programm?

If a server does not run or does not have a kernel which is secure enough you are bound to have downtime sometime in the near future. A good configured server can be maintained at the time it suits you, you can drop the RBAC temporarily and test the server without.

Since the server started ALSA you are already switching to the default runlevel (2, 3, 4 or 5). It means you can start it in runlevel 1 start sshd, start logging and switch to the default runlevel while watching "tail -f /var/log/syslog". The question should be "is uptime more important than finding an system error". A simple test like that should be possible within 2 hours on a quiet day.

Incidentally I have not upgraded my AMD64 to 2.6.28 yet so I only tested on 32-bit pc's (1 single core and 1 dualcore).

Don't know if anything relevant has changed in the second patch for 2.6.28.7 but my AMD64 X2 has just been updated to grsecurity-2.1.13-2.6.28.7-200903070930.
My 32-bit pc has been also been upgraded to grsecurity-2.1.13-2.6.28.7-200903070930.

Both booted without problems (Debian).

I've run this server for six years. Debian does constantly reinstall portmap (everytime they make a new debian stable and one dist upgrades ). It's annoying. If I turn off the server to test again and then have the kernel crash anyway my shell user's services go down.

Perhaps you should try "apt-get remove postmap dselect aptitude tasksel".

Programs like tasksel and dselect are made for users of typical workstations. I don't think a server can ever be counted as one of those.
Personally I think a server should be configured with minimal software installed and minimal software running. And a strict policy.

I don't think the age of the server has anything to do with it. Debian is a difficult system to learn. And I only learned to install debian using the netinstall CD (so I never used tasksel or dselect).

I agree on minimal software running and strict policy. I didn't mean for portmap to be running, I had removed it in the past. Sometimes one forgets what needs to be removed however. Also debian loves to change my permissions every update to things more permissive so I have a script to set the file perms each night and every restart.

Anyone have any ideas?