Installing Custom Kernel Modules in AED

Introduction

AED 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 AED kernel protects itself by preventing these changes. AED does this at the end of the init process, or the boot up process in Linux.

Specifically, AED locks the kernel right at the end of the process or at position S99. AED 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 AED, 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 AED 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 AED 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 AED GUI, click on AED 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 AED 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 AED, 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. AED 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

  • This is an example Linux bash script, which init uses to configure the system on boot. All shell scripts (bash is a shell script) require a token to start the script to tell the system that this is a both a script, and what interpreter to use to execute the script. The first line in the script is the token. The following lines contains commands that the interpreter, in this case “/bin/bash” will understand. Think of this as a list of commands you can run in the Linux shell.

    #!/bin/bash
modprobe xt_dscp

    Linux uses a special userspace tool called “modprobe” to insert kernel modules. You simply need to provide the name of the module to load it. You do not need to include the .ko in the module name, just the name of the module. For example, to load the xt_dscp.ko module you just need to use the name “xt_dscp” as in the example above.

    Save this script on the system using a text editor.

    Note

    Microsoft based text editors will not save files in a format that works on UNIX based systems. They place ^Ms at the end of every line, if you create a script in a Microsoft based editor you will need to fix the format of the file. Fortunately on UNIX based systems, like Linux, there is a command to do this. Just use the command “dos2unix <filename>” to fix the file, where <filename> is the literal filename to be fixed. For example:

    dos2unix S97_custom_modules

    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.