Linux Kernel module Security

Linux can dynamically load kernel modules. In many cases, you may need to ensure the security of kernel loading. If attackers load malicious kernel modules, the kernel will become extremely dangerous. Of course, the safe way is to sign the kernel module, and the kernel only loads the signature that can be correctly verified. This is the first thought of method. Of course, this method is not very simple. You need to use a public key encryption method, which is generally the rsa algorithm. The difficulty is to verify the signature of the module in the kernel, which requires modifying some corresponding points in the kernel. Obviously, the signature verification logic needs to be added at load_mod.pdf. To this end, we need to implement the rsa Algorithm in the kernel. The difficulty of implementing the rsa algorithm is the support of large numbers, which may always need libraries like mpi. In addition, the public key file needs to be resolved in the kernel and the interaction with the public key file at the application layer. The workload for these implementations is indeed not small, but it is gratifying that linux has already implemented these in the 3.7 kernel. In fact, these work previously existed in the form of patches. For more information, see http://lwn.net/Articles/470435/ , Called linux-modsign, finally finished in the 3.7 kernel. in fact, seeing that these are implemented in the 3.7 kernel does not make some people feel gratified. because the kernel version you use is not that high, it is estimated that it is 2.6. you may want to port 3.7 to 2.6. I think the workload is big enough to make people feel timid. kernel transplantation may cause instability and cause great troubles. slave http://lwn.net/Articles/470435/ Git address provided on http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-modsign.git/ In the history, we can see that the workload is still quite large. moreover, in order to provide versatility and scalability, the kernel uses some small frameworks and implements architecture-related and support for encryption hardware modules, which makes the source code hard to read and understand. If it was me, I would rather risk upgrading the kernel than trying to port the code. Of course, people familiar with the kernel can track linux-modsign to patch their systems, or implement a simplified version based on the principle. http://www.ee.ryerson.ca/~courses/coe518/LinuxJournal/elj2004-117-signedmodules.pdf ]. (After all, the main kernel implementation version is too complicated for individuals to handle it in a short time.) given the high risk of kernel modification, many may prefer to solve the problem at the user layer. this idea is good, because it avoids high-risk channels. the key issue is whether the problem can be solved in the user space. the result is no. it is unrealistic to rely entirely on the user layer to solve the security problem of the kernel module, or only part of the problem can be solved. it is impossible to achieve the same level of security issues of signature verification for the kernel module in the kernel. under the root permission, the security barriers of user space will be completely cracked. this is probably one of the main reasons why the Linux kernel uses the signature verification mechanism. indeed, this is the truth: operating systems cannot ensure security at the user layer without kernel support. But is the path to the user-Layer Space dead? Otherwise, we can find another path. With the support of the kernel module, you can verify the signature of the kernel module at the user layer. First, you need to implement a lsm module (for example, 2.6.32 in the kernel version, the register_security class symbols are no longer exported from the kernel, and the lsm module may need to be re-compiled dynamically, let the kernel export related symbols. For more information about the use of lsm, we will not introduce it here.) This module is mainly used to protect insmod from tampering, the protection module itself is not tampered with and related startup scripts are not tampered. It is not complex for lsm To Do This. It can be placed in a specific directory, so that lsm can stop any write operations on this directory. The kernel module uses the tool insmod or modprobe (which belongs to the system program provided by modutils) to load the kernel module. Finally, modprobe will call insmod to load the module. Insmod will eventually call the init_module system call to load the module. If you modify insmod and handle the signature verification logic before calling the init_module system, the premise is that the security of insmod should be ensured and insmod cannot be tampered with by attackers. Before the lsm module is loaded, it may run the contaminated insmod program. Of course, it can load malicious kernel modules. Therefore, after the system is started, load the lsm module first, and then load other modules. This is only theoretical. In fact, these processes are very fast, and attackers cannot launch attacks between these modules (because network services have not been enabled yet ). Therefore, the problem is transferred to ensure smooth loading of the lsm security module. Of course, this module may be loaded using insmod. (If it is compiled to the kernel and started with the kernel startup, this problem is guaranteed ). Therefore, insmod cannot be replaced, and the lsm module itself cannot be replaced. There are three key points: 1. insmod will not be replaced; 2. the lsm module must be correctly loaded. 3. The lsm module cannot be detached. (Uninstallation means that the security mechanism no longer works.) After problem 1 and problem 2 are solved, the kernel module can be protected without the root permission being obtained by attackers. Root permission will uninstall your lsm module, modify insmod, and then load malicious modules .... however, attackers cannot keep such attacks. After the next startup, the previously loaded malicious modules will not be loaded. From the above discussion, problems 1 and 2 can be solved: assume that the first time the system is started, it is absolutely safe. On this premise, the lsm module blocks any modification operations on the insmod and lsm modules (using the hook points of the lsm to achieve this is very easy, in fact, some sensitive scripts such as loading lsm modules need to be protected, even if the root permission does not work. This solves these two problems. The first launch is secure, which means that the lsm module is correctly loaded, so that the protection mechanism is established. The assumption is guaranteed, so it is feasible in principle. This problem seems like the insmod protects the kernel module, and the lsm module in turn protects the insmod and lsm module bytes to help each other achieve security. Question 3 is really tricky. If not, the system security level is not high enough. In fact, the easiest way to think of is to directly compile the lsm module into the kernel, which solves problems 2 and 3 together. however, we have to change the kernel again, but the changes here are much simpler than modifying load_module and other associated code in the kernel. Added the CONFIG_MODULE_UNLOAD flag to the 2.6 kernel to disable kernel module uninstallation. For more information, see http://www.ibm.com/developerworks/cn/linux/l-cn-kernelmodules/ . In fact, you can use programming skills to determine this problem. If you do not register the module module_exit function, the module cannot be uninstalled. Let's take a look at the code of the next hello kernel module:

#include <linux/module.h>#include <linux/kernel.h>#include <linux/init.h>static int __init lkp_init(void){    printk("<1>hello world! form the kernel sapce ...\n");    return 0;}static void __exit lkp_cleanup(void){    printk("<a>goodbye ,world,leaving kernel sapce ...\n");}module_init(lkp_init);//module_exit(lkp_cleanup);MODULE_LICENSE("GPL");

 

Here, I intentionally commented out module_exit (lkp_cheanup) and loaded the module to the kernel after compilation. You can see the information using lsmod:

[root@localhost hello]# lsmodModule                  Size  Used byhello                    501  0 [permanent]8021q                  20355  0 garp                    5703  1 8021qstp                     1626  1 garpllc                     4258  2 garp,stp…

 

As you can see, the hello module is marked as permanent, which means that the module is permanently loaded, that is, it cannot be uninstalled. Use rmmod below to test: root @ localhost hello] # rmmod hello. koERROR: Removing 'hello': Device or resource busy Cannot uninstall the module. It can be seen that this method can also achieve the effect, but it is also very simple. The above code test environment:

Cenos 6.4[root@localhost hello]# uname -aLinux localhost.localdomain 2.6.32-358.el6.i686 #1 SMP Thu Feb 21 21:50:49 UTC 2013 i686 i686 i386 GNU/Linux

 

It can be seen from the above that, based on the kernel module, the kernel module can be securely loaded with applications. This article briefly introduces the Linux kernel module security issue. With kernel 3.7's support for kernel module signature verification, this issue becomes increasingly simple. However, for many earlier versions of the kernel, you can use other methods to achieve the same function. If you have any better methods or suggestions, you are eager to be guided!