Hi,

I'm trying to gather information about what is absolutely necessary to be built into a static
kernel for my specific hardware and box's role(bare firewall - no services)

Been using dmesg output, lsmod and have been trying to wade though /proc/ksyms -which is
apparently a list of all the symbols this kernel is aware of ..so likely way more than necessary,
just what happens to be prebuilt,right? not whats actually in-use?

Its a stock slackware-current kernel, only diffrence between -current and 9.1 kernel is an xfs
diff I think

I'm vaguely aware of loadable kernel module exploits, but they seem to all be custom modules
- not unused stock modules that are hanging around on the system to get remotely loaded for
exploiting some vuln they might contain.. is this accurate?

I hear once a box is in a state where an attacker can load modules, its already compromised
anyway, so lkms arent what actually gains the attacker their access.. just what they install
afterwards to gain long-term control/go un-noticed?

The most detailed kernel info I've seen is in the kernel programming howto and the lfs docs..
but I'm still unclear on a few of these issues (attacker still need to first compromise a service
to gain intial access, or..?)

On a side note, has anyone gotten SELinux(Mandatory Access Control/Linux Secure Modules)
to work with slackware? I know debian and definately redhat are known to work, otherwise
the PaX kernel patches that are part of grsecurity seem nice.. some opinion on these?

Any help would be great, thanks in advance

If you want to avoid lkm's, don't use the modules feature in the kernel,
so no module can be loaded.
As for what's essential to be built in: everything that makes your hardware run ok.

I'm vaguely aware of loadable kernel module exploits, but they seem to all be custom modules
- not unused stock modules that are hanging around on the system to get remotely loaded for
exploiting some vuln they might contain.. is this accurate?
Yes. Using LKM's requires root capabilities (like CAP_SYS_MODULE), and (provided you don't run a vulnerable kernel version) so you need to exploit another condition on the box to gain root caps, so you wouldn't load stock modules unless you know there's a vulnerability to exploit.


I hear once a box is in a state where an attacker can load modules, its already compromised
anyway, so lkms arent what actually gains the attacker their access.. just what they install
afterwards to gain long-term control/go un-noticed?
Yes. LKM's aren't used to exploit the system but to hide processes, resources and files to hide the crackers presence and allow the cracker to keep control and return. If you have an integrity checker running (with databases on ro media) and do remote syslogging (and the syslog box can't be subverted) then it's impossible for the cracker to hide in the "noise".


On a side note, has anyone gotten SELinux(Mandatory Access Control/Linux Secure Modules)
to work with slackware? I know debian and definately redhat are known to work, otherwise
the PaX kernel patches that are part of grsecurity seem nice.. some opinion on these?
PAX is good but it doesn't cover everything (nothing can, OK) and you should look for additional measures beyond that feature. IMHO hardening the system (you already made a start by not running services) and hardening the running kernel, hardening processes, access restrictions, reducing capabilities, advanced logging etc etc should be mandatory on any server box that interacts with users (hell, all boxen). Both Grsecurity and LIDS provide those caps, and I would recommend adding any of them.


A temporary solution, and it doesn't prevent system subversion due to lack of hardening, but you can use "lcap" to take a way capabilities on a system wide scale if for some reason using Grsecurity or LIDS doesn't work for you. It's best done directly after all necessary system modules are loaded.

I can underline what unSpawn said. Uninstall all required services/software, set restrictive permissions to sensitve data like log files also to specific tools (dmesg & co).