Shulou(Shulou.com)06/01 Report--

This article mainly shows you "how to enhance access control security in the Linux kernel", which is easy to understand and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "how to enhance access control security in the Linux kernel".

Common interception and filtering in Linux

User dynamic library interception.

Kernel state system call interception.

Stackable file system interception.

Inline hook intercept.

LSM (Linux Security Modules)

Dynamic library hijacking

The hijacking of dynamic libraries on Linux is mainly based on LD_PRELOAD environment variables. The main function of this environment variable is to change the loading order of dynamic libraries so that users can selectively load the same functions in different dynamic libraries. However, improper use will cause serious security problems, through which we can load other dynamic functions in the main program and dynamic link library, which provides us with an opportunity to inject malicious code into other people's programs.

Suppose you have the following function for username and password authentication:

# include # include # include int main (int argc, char * * argv) {char passwd [] = "password"; if (argc

< 2) { printf("Invalid argc!\n"); return; } if (!strcmp(passwd, argv[1])) { printf("Correct Password!\n"); return; } printf("Invalid Password!\n"); } 我们再写一段hookStrcmp的程序，让这个比较永远正确。 #include int strcmp(const char *s1, const char *s2) { /* 永远返回0，表示两个字符串相等 */ return 0; } 依次执行以下命令，就会使我们的hook程序先执行。 gcc -Wall -fPIC -shared -o hookStrcmp.so hookStrcmp.c export LD_PRELOAD="./hookStrcmp.so" 结果会发现，我们自己写的strcmp函数优先被调用了。这是一个最简单的劫持 ，但是如果劫持了类似于geteuid/getuid/getgid，让其返回0，就相当于暴露了root权限。所以为了安全起见，一般将LD_PRELOAD环境变量禁用掉。 Linux系统调用劫持 最近发现在4.4.0的内核中有513多个系统调用(很多都没用过)，系统调用劫持的目的是改变系统中原有的系统调用，用我们自己的程序替换原有的系统调用。Linux内核中所有的系统调用都是放在一个叫做sys_call_table的内核数组中，数组的值就表示这个系统调用服务程序的入口地址。整个系统调用的流程如下：

When the user initiates a system call, it will enter the syscall hander through the 80 soft interrupt, and then enter the global system call table sys_call_table to find the specific system call, then if we change the address in this array to our own program address, we can achieve system call hijacking. But the kernel imposes some restrictions on this operation for the sake of security:

The symbol of sys_call_table is not exported and cannot be obtained directly.

The memory page on which sys_call_table is located is read-only and cannot be modified directly.

For the above two problems, the solution is as follows (in more than one way):

Get the address of sys_call_table:

Grep sys_call_table / boot/System.map-uname-r

The read-only property of the control page table is controlled by the WP bit of the CR0 register, and the read-only page table can be modified by clearing this bit.

/ * make the page writable * / int make_rw (unsigned long address) {unsigned int level; pte_t * pte = lookup_address (address, & level); / / find the page table address pte- > pte where the virtual address is located | = _ PAGE_RW;// set page table read and write properties return 0;} / * make the page write protected * / int make_ro (unsigned long address) {unsigned int level; pte_t * pte = lookup_address (address, & level); pte- > pte & = ~ _ PAGE_RW / / set the read-only property return 0;}

1. Start replacing system calls

This article implements the system call corresponding to the command ls, and the system call number is _ _ NR_getdents.

Static int syscall_init_module (void) {orig_getdents = sys_call_ table [_ _ NR_getdents]; make_rw ((unsigned long) sys_call_table); / / modify the page attribute sys_call_ table [_ _ NR_getdents] = (unsigned long *) hacked_getdents; / / set the new system call address make_ro ((unsigned long) sys_call_table); return 0;}

two。 Restore the original state

Static void syscall_cleanup_module (void) {printk (KERN_ALERT "Module syscall unloaded.\ n"); make_rw ((unsigned long) sys_call_table); sys_call_ table [_ _ NR_getdents] = (unsigned long *) orig_getdents; make_ro ((unsigned long) sys_call_table);}

Using Makefile compilation, after insmod inserts the kernel module, and then executes ls, it will enter our system call, we can delete some files in the hook code, ls will not display these files, but these files still exist.

Stackable file system

Linux abstracts the specific disk file system through the vfs virtual file system, and the IO stack from top to bottom forms a stack. Through the analysis of the kernel source code, taking a read operation as an example, the process from top to bottom is as follows:

The kernel uses a lot of object-oriented in the form of c language, that is, in the form of function pointers. For example, read is the user interface provided by vfs, specifically calling the read operation of ext2. As long as we implement the various interfaces provided by VFS, we can implement a stack file system. Some stack file systems have been integrated into the Linux kernel. For example, Ubuntu will remind you whether you need to encrypt the home directory during installation, which is actually a stack encrypted file system (eCryptfs) based on the following principles:

The implementation of a stack file system, equivalent to all read and write operations will enter our file system, you can get all the data, you can do some interception and filtering.

The following is one of the simplest stackable file systems I have implemented, which realizes the simplest way to open, read and write files. The sparrow is small but well-equipped.

Https://github.com/wangzhangjun/wzjfs

Inline hook

We know that functions in the kernel cannot implement all the functions in this function, and it must call its lower-level functions. If this lower-level function can get the filtering information content we want, we can replace the offset of the lower-level function in the upper-level function with the offset of the new function, so that when the upper-level function calls the lower-level function, it will jump to the new function and do the work of filtering and hijacking the content in the new function. So in principle, inline hook can hook wherever it wants to hook.

Inline hook has two important issues:

How to locate hook points.

How to inject the hook function entry.

1. For * questions:

You need to have some kernel source code experience. For example, for read operations, the source code is as follows:

Here, when you initiate a read system call, you will enter sys_read, and the vfs_read function will be called in sys_read. There is exactly the information we need to filter in the parameters of vfs_read, so you can regard vfs_read as a hook point.

two。 For the second question:

How to Hook? Here are two ways:

* the binary substitution is performed directly, replacing the Operand of the call instruction with the address of the hook function.

The second way: the kprobes mechanism provided by the Linux kernel.

The principle is that the machine code of int 3 (x86) is injected into the hook point, and when cpu runs here, the sig_trap signal will be triggered, and then the user-defined hook function will be injected into the callback function of sig_trap to achieve the purpose of triggering the hook function. This is actually the principle of the debugger.

LSM

LSM is the abbreviation of Linux Secrity Module, that is, linux security module. It is a general Linux security framework, which is efficient, easy to use and so on. The principle is as follows:

LSM does the following in the kernel:

Join a security domain in a specific kernel data structure.

Different key points in the kernel source code insert calls to the security hook function.

Add a general security system call.

Functions are provided to allow kernel modules to register as security modules or log out.

Transplant most of the capabilities logic into an optional security module, which is extensible.

Applicable scenario

For the above several Hook methods, there are different application scenarios.

Dynamic library hijacking is not complete, the hijacked information may not meet our needs, or someone else may hijack it before you, and once you disable LD_PRELOAD, it will become invalid.

System call hijacking, hijacked information may not meet our needs, for example, can not get the struct file structure, can not get the absolute path of the file, and so on.

Stackable file systems, which depend on Mount, may need to be rebooted.

Inline hook, high flexibility, arbitrary Hook, no need to restart immediately, but poor versatility between different kernel versions, once some functions have changed, Hook is invalid.

LSM, in the early kernel, can only allow one LSM kernel module to load, for example, if you load SELinux, you cannot load other LSM modules. This problem does not exist in the kernel version of * *.

The above is all the contents of the article "how to enhance access Control Security in the Linux Kernel". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.