Installing custom kernel modules with ASL

Introduction

ASL protects Linux systems in many ways. One of the ways it protects Linux systems from kernel level rootkits is to lock the kernel from any additional changes. Unlike a normal Linux kernel, which can be modified on the fly and can have its code changed anytime - by a malicious person for example - an ASL kernel protects itself by preventing these changes. ASL does this at the end of the init process, or the boot up process in Linux.

Specifically, ASL locks the kernel right at the end of the process or at position S99. ASL will load whatever modules the system is configured to load during boot and once that is complete it will prevent any future changes to the kernel.

This is the default behavior for ASL, to lock the kernel. So, if you stuck to the defaults (which we recommend, allowing the kernel change on the fly is very insecure and is not necessary), or if you set ASL to lock the kernel (which you are highly encouraged to do) you will see an error if you try to load a kernel module once the system finishes booting up.

To load custom modules you need to configure the system to do this during boot up, and the best place to do that is before init reaches position S99. The rest of this article explains init, what it does, what those positions are and how we recommend you load custom modules. This will vary from system to system as you may need to load those modules earlier in the init process.. Therefore check with your OS or third party product vendor to find out where in the boot process to load those modules.

Your other option is to configure ASL to behave like a normal Linux kernel, this is to allow the kernel to modified at any time, by malicious and non-malicious users. You can do that by logging into the ASL GUI, click on ASL Configuration, scroll down to kernel and set modules to load. You will then need to reboot your system. We do not recommend you set this and ASL will alert you to this vulnerable condition your system is now in.

init primer

init is the master program, if you will, for all UNIX systems (init is not part of ASL, please contact your OS vendor for support with init). Everything is a child of init, its process 1. (And no, you can't kill it - go ahead! Its safe!)

So when the system starts up init will start up everything for you, and carry out all the tasks needed to setup the system - like turning on networking and loading modules. init does this by "runlevel", these levels roughly correlate to the "function" of the system - dont get hung up on this, UNIX is OLD so these are concepts that dont matter as much as they used to. When init starts it checks the file /etc/inittab - that file tells it the "run level" to start up. This allows a UNIX system to basically have different levels or configurations depending on need. In practice, this isnt really used by most people. In practice most Linux systems will either start run level "3" or run level "5". These levels basically mean:

 3 - multi user system with remote services (a server)

 5 - multi users system with remote services and a big heavy GUI (a desktop basically)

And in case anyone is wondering, 2 used to mean multi-user server but without things like NFS, etc. And run level 1 is "single user" a special mode that starts UNIX/Linux in todays world into a maintainence/oh my god I broke it mode. (In the past it actually meant single user)

The levels ultimately are arbitrary, and heres why. All that happens when you tell init to run at a "level" is that it runs the scripts in a different directory. You see, init just runs in numerical order all the scripts in one of these directories:

 /etc/rc1.d/
 /etc/rc2.d/
 /etc/rc3.d/
 /etc/rc4.d/
 /etc/rc5.d/

And those numbers refer to run levels. So, if you look in /etc/inittab you'll see a line like this:

 id:3:initdefault:

So that tells init to run every script in this directory - and only the scripts in this directory:

 /etc/rc3.d/

Inside that directory you will see scripts that start with S and K. S means do this on start, K means do this when the system shuts down. Scripts are run in numerical order, so S00 runs before S01. S10 runs before S99, and so on. ASL locks the kernel at positions S99, so any init script running before S99 can load/unload all the modules it wants.

In modern Linux systems you will see all the files in /etc/rcN.d (where N is a number as expressed above) as symlinks to this directory:

 /etc/init.d/

That directory is typically where the actual scripts are to prevent duplication of the scripts in all the /etc/rcN.d/ directories.

Load the custom module

So, if you want to load modules before S99, then create a script in /etc/rc3.d/ with a number less than 99. S98_custom_modules for example.

You can also put your custom module script in /etc/init.d/ and symlink to it like this:

 ln -s /etc/init.d/custom_modules S98custom_modules

You do not have to do it this way, you can also put your script in the /etc/rcN.d directory that is correct for your system, you can also just modify the init scripts to load whatever modules you when those scripts run.

Example script

#!/bin/bash
modprobe xt_dscp 

For a script to run it also needs to have permission to execute, so when you save the file to your /etc/rcN.d directory, make sure its executable. A simple way to do that is to run this command as root:

chmod u+x /etc/rcN.d/S97_custom_modules

Again, read this entire article so you know what to change "N" to, as there is no /etc/rcN.d directory.