On my laptop, I have REENABLED module loading! (Which is bad

[mikeeusa2]

On my laptop, I have REENABLED module loading! (Which is bad for security):

The LOG!:

r00t@debian:~$
(Oh, this is just a bluff, he busting out the console all just saying and playing and such)
r00t@debian:~$ su
(Oh comon now, you know you ain't going to do shit)
Password:
debian:/home/r00t#
(pfft, he's just fronting)
debian:/home/r00t# cat /etc/X11/xdm/Xsetup
#!/bin/sh
#
# $Id$
#
# This script is run as root before showing login widget.

#xsetroot -solid rgb:8/8/8
Esetroot /usr/share/backgrounds/packeterror.png
/bin/echo 419224 > /proc/sys/fs/file-max
/bin/echo 0 > /proc/sys/net/ipv4/tcp_timestamps
/bin/echo 0 >/proc/sys/net/ipv4/tcp_ecn
/bin/echo > /proc/sys/kernel/core_pattern

/sbin/sysctl -w kernel.grsecurity.disable_modules="1"
/sbin/sysctl -w kernel.grsecurity.grsec_lock="1"

LD_PRELOAD=/lib/libsafe.so.2
export LD_PRELOAD


debian:/home/r00t#

(woah woah, dude comon, don't do that, just leave it the fuck alone!)

debian:/home/r00t# jed /etc/X11/xdm/Xsetup
(no dude, STOP.)
debian:/home/r00t# cat /etc/X11/xdm/Xsetup
#!/bin/sh
#
# $Id$
#
# This script is run as root before showing login widget.

#xsetroot -solid rgb:8/8/8
Esetroot /usr/share/backgrounds/packeterror.png
/bin/echo 419224 > /proc/sys/fs/file-max
/bin/echo 0 > /proc/sys/net/ipv4/tcp_timestamps
/bin/echo 0 >/proc/sys/net/ipv4/tcp_ecn
/bin/echo > /proc/sys/kernel/core_pattern

/sbin/sysctl -w kernel.grsecurity.disable_modules="0"
/sbin/sysctl -w kernel.grsecurity.grsec_lock="1"

LD_PRELOAD=/lib/libsafe.so.2
export LD_PRELOAD

debian:/home/r00t#
(You FUCKING SCUMBAG, WHAT THE FUCK! NOW ANYONE WHO GETS ROOT HAS MEGA PWND YOU YOU FUCKING RETARD MOTHER FUCKER!)

I'm sorry, parentheses, I usually have my laptop booted up for weeks, with the modules disabled I can't use alot of my peripherals. I need module support for USB things (usb keys and usb sound devices) and my pcmcia wireless card.
If it is any consolation, I did not compile in firewire support.

Spender and PaXteam and others: what is your opinion of my actions in this instance? On my server modules are disabled still (no problems there).

[mikeeusa2]

One thing though, with modules disabled I hadn't had had even ONE lockup, previously (on earlier kernels, non-grsec) when I put in or took our my wifi card, or disabled it, changed Mac address (yea, that is how I roll about! (!!)) the computer had a 1/4th chance of locking up. Same for when the wifi router turned off nightly (have it on a timer, otherwise it becomes unresponsive after 2 days or so), 1/4th chance of laptop locking up.

[mikeeusa2]

I went there. I reenabled modules. I know this is bad for security. I'm slipping. It's like how people start with cigaretts, move to cocain, and end with cancer.

[cormander]

Just load all the modules you'll need before you lock module loading. It's not like they can get removed afterward, right?

[mikeeusa2]

I never know which one's I'll need.

[cormander]

Just off the top of my head, modules are usually logged somewhere when they get loaded. This is kind of hack-n-slash'ish, but consider doing something like this:

Code: Select all

for ko in $(find /lib/modules/$(uname -r)/kernel -name '*.ko'); do
    mod=$(basename $ko | sed 's/\.ko$//');
    grep -R $mod /var/log/ &> /dev/null
    [ $? -eq 0 ] && echo $mod;
done > mod_list


On my system, line count of lsmod vs. line count of the above output are close enough that you wouldn't be loading too many extra modules:

Code: Select all

# lsmod | wc -l
84

# wc -l mod_list
119 mod_list


Then in your init script, just do something like:

Code: Select all

for mod in $(cat mod_list); do
    modprobe $mod
done


You'd do this right before you locked modules.

[mikeeusa2]

Is there a way I can only allow modules to be loaded from the linux kernel's module directory and disallow writing etc to that directory?

[cormander]

Now that's an interesting idea, great 'out of the box' thinking there. Mine was kind of mad scientist'ish; maybe I shouldn't be giving technical advice at 1am.

As far as I know, you can either insert code into the kernel via a module, or you can't; where it is on the filesystem isn't taken into account. Perhaps you can do something like this with the RBAC system, but as far as I know, moudle loading control via policy it isn't currently coded.

If you have TPE enabled and have your RBAC policy so you can't write anywhere to your $PATH, modify your $PATH, or write to anything inside of /lib/*, then a rule saying insmod can only read stuff inside /lib/* should do the trick. It's as safe as you're going to get while leaving modules insertable.

But of course, that means you have to actually use the rbac system, and when its disabled, you're not protected at all.

[mikeeusa2]

Can spender add this idea!
(It's not from me, the idea is from divverent, the main programmer of the nexuiz project)

[tjh]

Aren't you essentially asking for the RBAC system to be implemented?

[mikeeusa2]

To my limited knowlege, the RBAC system doesn't have flags to say "you can load kernel modules from the directory" (and no others).
I used the RBAC system 2 years ago last time though.

[specs]

Don't know if I find the idea that great.

How do you upgrade kernels (and modules)?
Mostly I do a "make modules_install" as root AND I add a few missing modules. Those missing modules are the main problem. Some added modules are a pain to compile and need to be adjusted (i.e. replaced) after the kernel is booted.

After the missing modules are added there is normally no need to add further modules though.

Like the /proc option one could limit the access to /lib/modules. In fact I tried "chmod 700 /lib/modules" on some systems and this causes no real problem. It is not a very strong protection either. Question is if there is any advantage when "lsmod" can still be used as a normal user.

Limiting insmod to only work using /lib/modules/{$KERNELVERSION} seems be a little more secure. But how do you check if insmod reads for /lib/modules/{$KERNELVERSION} and does not slip in some different module? In fact I do wonder if you are implicitely asking for an in-kernel version of insmod/modprobe.

If you start making /lib/modules/* read-only I'd suggest a sysctl option to disable this feature. Otherwise you'd need a special kernel without this option to be able to upgrade at all.
If you only protect the running kernel I think you are just waisting your time (because the exploit is only waiting for the next reboot).
The other option is of course implementing an RBAC which should be sufficient for these kind of tasks. Not every security option needs to be implemented in the kernel.

[mikeeusa2]

IIRC, an RBAC that does that doesn't currently exist. It would be a nice feature.

[mikeeusa2]

Any way to do this?

[specs]

You still haven't told what won't work if you load ALL MODULES at boot time and disable module loading. You can try to minimize the modules you compile and load simply by trial and error. The learning traject is short and fast.

If you have a problem with the risks off added functionality the best way to deal with it is either blocking module loading or not using modules at all (sometimes this is used to create a smaller footprint for embedded systems). You can try optimizing your system to be able to reboot very fast in case you do need to add one module (after the prompt 5 seconds for a netbook or about 14 for a "normal" workstation, http://www.debian-administration.org/articles/620 ).

If you really like a "soft" option to be able to enable and disable kernelloading why don't you change the kernel sources? You only need to change the sources to be able to re-enable module loading again after blocking. The option to block is there. You only need to be able to change the 1 in a 0 again...

However, I don't think an option to disable and re-enable module loading will increase the kernel security in any way.
I also don't see why you should optimize a personal computer system for at least a week uptime and still expect maximum security.