Difference between revisions of "Installing custom kernel modules with ASL"

From Atomicorp Wiki
Jump to: navigation, search
(Created page with '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 no…')

Revision as of 11:39, 17 December 2009

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, S99 to be specific to allow a Linux system to change the kernel as necessary, for example to load modules, and once that is complete to prevent any future changes. 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 do this during boot up, and the best place to do that is before init reached S99. The rest of this article explains init, what it does, and what 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, check with the vendor of the product you are using to find out where to load those modules.

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.

Personal tools