Installing custom kernel modules with ASL

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, or 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. 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 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.

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.