Please see this FAQ:

https://www.atomicorp.com/wiki/index.ph ... _permitted

Do you have rules that look at the DSCP field?

Solution:

By default the ASL kernel doesn't allow loading (or unloading) of kernel modules during runtime to protect the system from kernel level rootkits and other malicious kernel level code. Once your system finished the boot up process ASL will lock the kernel preventing hackers from modifying your kernel and hiding malware on your system. When attempting to load modules dynamically, this may result in error messages such as this:

modprobe: WARNING: Error inserting sunrpc (/lib/modules/2.6.32.43-6.art.i686.PAE/kernel/net/sunrpc/sunrpc.ko): Unknown symbol in module, or unknown parameter (see dmesg) modprobe: WARNING: Error inserting auth_rpcgss (/lib/modules/2.6.32.43-6.art.i686.PAE/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko): Unknown symbol in module, or unknown parameter (see dmesg)

You have two options with ASL:

1) Set the modules to load at boot and reboot your system.

This article: Installing custom kernel modules with ASL provides more information about setting up custom modules to load before ASL locks the kernel down.

2) Configure ASL to allow your kernel to be modified at any time.

This is NOT recommended and is highly insecure. Allowing kernel modules to dynamic load and unload on a running system makes it possible for an attacker to install a kernel module rootkit. Kernel level rootkits are the most difficult type of malware to detect and prevent. Once the kernel is compromised, the entire system is compromised and it may not be possible for you even detect that this as occurred. We highly recommend you load the modules you need on boot and let ASL lock the kernel. Remember, ASL prevents all LKM rootkits if module loading is prevented at runtime.

If you wish to use to make your kernel insecure and to allow dynamic module loading on the fly, log into the ASL GUI, click on ASL Configuration and change the setting ALLOW_kmod_loading to yes. You will then need to reboot the system for this change to take effect. ASL will report this, correctly, as a critical vulnerability in the system.

Thank you for the question. Anything before S99asl-mod runs, thats when the kernel is locked.

Setting up your system to load custom modules is explained in this FAQ:

https://www.atomicorp.com/wiki/index.ph ... el_modules.

Which I have included below for your convenience, specifically see option 1:

1) Set the modules to load at boot and reboot your system.

This article: Installing custom kernel modules with ASL provides more information about setting up custom modules to load before ASL locks the kernel down.

No, that will not work. Please see the article linked to in option 1 above, I've included the the option again for your convenience:

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.
[edit] 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.

<pre>
#!/bin/bash
modprobe xt_dscp
</pre>

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 edit.

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

This will fix the file.

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.

So .ko files are not scripts, they are kernel objects. You can't load them by creating a symlink to them, you have to tell the system to load them.

Kernel modules are loaded in Linux via the command "modprobe". So you need to create a script to run that command.