Methods to enhance access control security in Linux kernel

background

Some time ago, our project team was helping customers solve some problems in the field of operating system security, involving the three major operating system platforms: Windows, Linux, and macOS. No matter what operating system it is, it is essentially a software. When any software is first designed, it cannot meet people's needs 100%, so the same is true for operating systems. In order to meet people's needs as much as possible, some mechanisms have to be provided for people to customize the operating system. Of course, in addition to some official mechanisms, there are also some black magic. These black magic are not recommended for use, but sometimes they can be used as a reference when facing specific business scenarios.

Common interception and filtering in Linux

This article focuses on the common interceptions on the Linux platform:

• User-mode dynamic library interception.
• Kernel-mode system call interception.
• Stackable file system interception.
• Inline hook interception.
• LSM (Linux Security Modules)

Dynamic library hijacking

Dynamic library hijacking on Linux is mainly based on the LD_PRELOAD environment variable. The main function of this environment variable is to change the loading order of dynamic libraries, allowing users to selectively load the same functions in different dynamic libraries. However, improper use will cause serious security problems. We can use it to 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 there is the following username and password verification function:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
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");
}

Let's write another hookStrcmp program to ensure that the comparison is always correct.

#include <stdio.h>
int strcmp(const char *s1, const char *s2)
{
/* Always returns 0, indicating that the two strings are equal*/
return 0;
}

Executing the following commands in sequence will cause our hook program to execute first.

gcc -Wall -fPIC -shared -o hookStrcmp.so hookStrcmp.c
export LD_PRELOAD="./hookStrcmp.so"

As a result, we can find that the strcmp function we wrote ourselves is called first. This is the simplest hijacking, but if you hijack something like geteuid/getuid/getgid and make it return 0, it is equivalent to exposing root permissions. So for safety reasons, the LD_PRELOAD environment variable is generally disabled.

Linux system call hijacking

Recently, it was discovered that there are more than 513 system calls in the 4.4.0 kernel (many of which have never been used). The purpose of system call hijacking is to change the original system calls in the system and replace the original system calls with our own programs. All system calls in the Linux kernel are placed in a kernel array called sys_ call _table, and the value of the array represents the entry address of the system call service program. The entire system call process is as follows:

When a system call is initiated in user mode, 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. If we change the address in this array to our own program address, we can achieve system call hijacking. However, for security reasons, the kernel has made some restrictions on this operation:

• The symbols of sys_ call _table are not exported and cannot be obtained directly.
• The memory page where sys_ call _table is located is read-only and cannot be modified directly.

For the above two problems, the solutions are as follows (there is more than one method):

• Get the address of the sys call table: grep sys_call_table /boot/System.map-uname -r
• The read-only attribute of the page table is controlled by the WP bit of the CR0 register. 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 where the virtual address is located pte->pte |= _PAGE_RW;//Set the page table read and write attributes 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 read-only attribute return 0;
}

Start replacing system calls

This article implements the system call corresponding to the ls command. 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 page attributessys_call_table[__NR_getdents] = (unsigned long *)hacked_getdents; //Set new system call addressmake_ro((unsigned long)sys_call_table);
return 0;
}

Restoration

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);
}

Use Makefile to compile, insert the kernel module with insmod, and then execute ls, it will enter our system call. We can delete certain files in the hook code, and ls will not display these files, but these files still exist.

Stacked file system

Linux uses the vfs virtual file system to unify and abstract specific disk file systems, forming a stack-like IO stack from top to bottom. Through the analysis of the kernel source code, taking a read operation as an example, the process executed from top to bottom is as follows:

The kernel uses a lot of object-oriented programming in the form of C language, that is, in the form of function pointers. For example, read is the interface provided by vfs to users, and the specific call underneath is the read operation of ext2. As long as we implement the various interfaces provided by VFS, we can realize a stack file system. Some stacked file systems have been integrated into the Linux kernel. For example, when installing Ubuntu, you will be prompted to encrypt your home directory. This is actually a stacked encrypted file system (eCryptfs). The principle is as follows:

A stack file system is implemented, which means that all read and write operations will enter our file system, so we can get all the data and do some interception and filtering.

The following is the simplest stack file system I implemented, which implements the simplest way to open, read and write files. It is small but complete.

https://github.com/wangzhangjun/wzjfs

inline hook

We know that it is impossible for a function in the kernel to implement all its functions in this function, it must call its lower-level functions. If this lower-level function can obtain the filtered 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. In this way, when the upper-level function calls the lower-level function, it will jump to the new function and perform filtering and hijacking content in the new function. So in principle, inline hook can hook wherever you want.

There are two important issues with inline hooks:

• How to locate the hook point.
• How to inject hook function entry.

For the first question:

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

Here, when the read system call is initiated, it will enter sys read, and the vfs read function will be called in sys read. The parameters of vfs read contain the information we need to filter, so we can use vfs_ read as a hook point.

For the second question:

How to Hook? Here are two methods:

The first method is to directly perform binary replacement and replace the operand of the call instruction with the address of the hook function.

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

The principle is to inject the machine code of int 3 (x86) at the hook point, so that when the CPU runs here, it will trigger the sig trap signal, and then inject the user-defined hook function 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, which means Linux security module. It is a general Linux security framework with the characteristics of high efficiency, simplicity and ease of use. Here’s how it works:

LSM

The following work is done in the kernel:

• Add security domains to specific kernel data structures.
• Insert calls to security hook functions at different critical points in the kernel source code.
• Add a common security system call.
• Functions are provided to allow kernel modules to register as security modules or unregister them.
• Most of the capabilities logic is migrated to an optional security module for scalability.

Applicable scenarios

The above Hook methods have different application scenarios.

• Dynamic library hijacking is not complete. The hijacked information may not meet our needs. It is also possible that someone else has hijacked it before you. Once LD_PRELOAD is disabled, it will become invalid.
• System call hijacking, the hijacked information may not meet our needs, such as being unable to obtain the struct file structure, unable to obtain the absolute path of the file, etc.
• Stacked file systems rely on Mount and may require a system reboot.
• Inline hook is highly flexible and can be hooked at will. It takes effect immediately without restarting. However, it has poor compatibility between different kernel versions. Once some functions are changed, the hook will become invalid.
• LSM, in early kernels, only one LSM kernel module was allowed to be loaded. For example, if SELinux was loaded, other LSM modules could not be loaded. This problem does not exist in the latest kernel version.

Summarize

Due to limited space, this article only introduces the interception technology on Linux. We will have the opportunity to discuss the interception technology on Windows and macOS later. In fact, similar audit hooks are a rigid demand in any system, not just the kernel. We can see that more and more VMs and runtimes, even many web components and front-end applications, provide more flexible hook methods. This is the most common solution under the two major security trends of transparency and real-time performance.

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. If you have any questions, you can leave a message to communicate. Thank you for your support for 123WORDPRESS.COM.