How to enhance the security of Linux system, Part one: Introduction to the Linux Security Module (LSM)

HTTP://WWW.IBM.COM/DEVELOPERWORKS/CN/LINUX/L-LSM/PART1/1. Related background: Why and what

In recent years, Linux system has been widely concerned and applied by computer industry because of its excellent performance and stability, the flexibility and expansibility of open Source feature, and the lower cost. But in terms of security, the Linux kernel only provides classic UNIX autonomic access control (root, user ID, mode bit security), And partly supports the capabilities security mechanism in the draft POSIX.1E Standard, which is not enough for the security of Linux system, which affects the further development and wider application of Linux system.

There are many security access control models and frameworks that have been researched and developed to enhance the security of Linux systems, more well-known security Enhanced Linux (SELinux), Domain and type enhancement (DTE), and Linux Intrusion Detection systems (lids), among others. However, since no system can gain dominant status and enter the Linux kernel as standard, and these systems are mostly in the form of a variety of kernel patches, the use of these systems requires the ability to compile and customize the kernel, for non-core development experience for ordinary users, access to and use of these systems is difficult. At the 2001 Linux Kernel Summit, the U.S. National Security Agency (NSA) introduced their work on security Enhanced Linux (SELinux), a flexible access control system flask in Linux, when the founders of the Linux kernel Linus Torvalds agrees that the Linux kernel does require a common security access control framework, but he points out that it is best to use a method that can load kernel modules to support the various existing security access control systems. As a result, the Linux Security Module (LSM) came into being.

The Linux Security Module (LSM) is a lightweight universal access control framework for the Linux kernel. It enables various security access control models to be implemented in the form of Linux loadable kernel modules, allowing users to choose the appropriate security module to load into the Linux kernel, which greatly improves the flexibility and ease of use of the Linux secure access control mechanism. There are already many well-known enhanced access control systems ported to the Linux Security Module (LSM) implementations, including POSIX.1E capabilities, security enhanced Linux (SELinux), Domain and type enhancement (DTE), and Linux Intrusion Detection system (lids) and so on. While the current Linux security Module (LSM) is still available as a Linux kernel patch, it also provides a series of Linux 2.4 stable versions and Linux 2.5 development versions, and hopefully goes into the Linux 2.6 stable version, The goal is to be accepted by the Linux kernel as a standard for Linux kernel security, which is available to users in various Linux distributions.

Back to top of page

2. Introduction to design ideas: to be satisfied with both sides

The design of the Linux Security Module (LSM) must be designed to meet the requirements of two people: to get as few of them as possible, and so that people who need it can get useful and efficient functions.

The kernel developer, represented by Linus Torvalds, made three points for the Linux Security Module (LSM):

• Real universal, when using a different security model, only need to load a different kernel module
• It is conceptually simple, has minimal impact on the Linux kernel, is efficient, and
• Ability to support existing POSIX.1E capabilities logic as an optional security module

On the other hand, the requirements of the Linux Security Module (LSM) for various Linux security enhancement systems are to allow them to re-implement their security functions as loadable kernel modules without significant security losses or additional overhead.

To meet these design goals, the Linux Security Module (LSM) uses the method of placing hooks in the kernel source code to arbitrate access to internal kernel objects: tasks, inode nodes, open files, and so on. The user process performs system calls, first traveling through the original Linux kernel to find and allocate resources, perform error checking, and undergo classic UNIX autonomic access control, just before the Linux kernel attempts to access the internal objects, A Linux security module (LSM) hook makes a call to the function that the security module must provide, so that the security module raises the question "is access execution allowed?" , the security module makes a decision based on its security policy and responds by allowing, or rejecting, returning an error.

On the other hand, to meet the needs of most existing Linux security enhancement systems, the Linux Security Module (LSM) has adopted a simplified design decision. The Linux Security Module (LSM) Now primarily supports the core functionality of most existing security-enhanced systems: access control, and a small amount of support for additional security features, such as security audits, that are required by security-enhancing systems. The Linux Security Module (LSM) now primarily supports "restricted" access control decisions: When the Linux kernel gives access, the Linux Security Module (LSM) may reject, and when the Linux kernel denies access, it skips over the Linux security Module (LSM), and for the opposite "Allowed" access control decisions provide only a small amount of support. For module function synthesis, the Linux security Module (LSM) allows the module stack, but leaves the main work to the module itself: The final decision of the module's functional synthesis by the first loaded module. All of these design decisions may temporarily affect the functionality and flexibility of the Linux Security Module (LSM), but significantly reduce the complexity of the Linux Security Module (LSM) implementation and reduce the modification and impact of the Linux kernel. The likelihood of getting into the Linux kernel as a security standard is greatly improved, and by becoming a standard, you can change decisions, add functionality and flexibility.

Back to top of page

3. Introduction to implementation: Modifications to the Linux kernel

The Linux Security Module (LSM) is now implemented as a patch of a Linux kernel. Instead of providing any specific security policy, it provides a common infrastructure for security modules, and security modules to implement specific security policies. It modifies the Linux kernel in five main ways:

• Added a security domain to a particular kernel data structure
• A call to a secure hook function is inserted into different key points in the kernel source code
• Added a common security system call
• A function is provided to allow the kernel module to be registered as a security module or to log off
• Porting most of the capabilities logic to an optional security module

The following five aspects of the changes to do a brief introduction.

A security domain is a pointer to a void* type that enables the security module to link security information to internal kernel objects. The following lists the kernel data structures that have been modified to include the security domain, as well as the internal kernel objects that each represent:

• Task_struct structure: Representing tasks (processes)
• LINUX_BINPRM Structure: Representative Program
• Super_block structure: Representing the file system
• Inode structure: Represents a pipeline, file, or socket socket
• File structure: represents open files
• Sk_buff structure: Represents the network buffer (package)
• Net_device structure: Representing network equipment
• Kern_ipc_perm structure: Represents a semaphore signal, a shared memory segment, or a message queue
• Msg_msg: Represents a single message

In addition, the MSG_MSG structure, the msg_queue structure, and the shmid_kernel structure are moved to the two header files of include/linux/msg.h and include/linux/shm.h, enabling the security module to use these definitions.

The Linux Security Module (LSM) provides two types of calls to secure hook functions: A class of security domains that manage kernel objects, and another class of quorum access to these kernel objects. The call to the secure hook function is implemented by hooks, which are function pointers in global table security_ops, the type of the global table is the security_operations structure, which is defined in include/linux/ Security.h This header file, this structure contains a sub-structure consisting of hooks grouped by kernel object or kernel subsystem, and some top hooks for system operation. It is easy to find the call to the hook function in the kernel source code: its prefix is security_ops->. A detailed description of the hook function is left behind.

The Linux Security Module (LSM) provides a common security system call that allows security modules to write new system calls for security-related applications, similar in style to the original Linux system call Socketcall (), which is a multi-channel system call. This system call is security () with the parameters (unsigned int id, unsigned int call, unsigned long *args), where the ID represents the module descriptor, calling represents the invocation descriptor, and args represents the argument list. This system call provides a sys_security () entry function by default: it simply calls the sys_security () hook function with arguments. If the security module does not provide a new system call, you can define the sys_security () hook function that returns-ENOSYS, but most security modules can define the implementation of the system call themselves.

During kernel boot, the Linux security Module (LSM) framework is initialized to a series of virtual hook functions to implement the traditional UNIX super-user mechanism. When loading a security module, the security module must be registered with the Linux Security Module (LSM) framework using the register_security () function: This function will set the global table Security_ops to point to the hook function pointer of the security module. This allows the kernel to ask the Security module for access control decisions. Once a security module is loaded, it becomes the security Policy Decision Center of the system and is not overwritten by the subsequent register_security () function until the security module is used Unregister_security () The function unregisters the framework: this simply replaces the hook function with the default, and the system returns to the UNIX super-user mechanism. In addition, the Linux Security Module (LSM) framework provides functions mod_reg_security () and function mod_unreg_security () so that subsequent security modules can be registered and unregistered with the first registered Master module. However, the policy implementation is determined by the main module: is to provide a strategy to implement the module stack to support module function synthesis, or simply return the error value to ignore the subsequent security module. These functions are provided in the kernel source code file SECURITY/SECURITY.C.

The Linux kernel now provides support for a subset of POSIX.1E capabilities. One of the requirements of the Linux Security Module (LSM) design is to port this functionality to an optional security module. POSIX.1E capabilities provides the ability to divide traditional superuser privileges and assign them to specific processes. The Linux Security Module (LSM) retains the existing capable () interface used to perform capability checks in the kernel, but simplifies the capable () function to the wrapper of a Linux security module (LSM) hook function, This allows any required logic to be implemented in the security module. The Linux Security Module (LSM) also retains the set of process capability (a simple bit vector) in the Task_struck structure and does not move it to the security domain. The Linux kernel's support for capabilities also includes two system calls: Capset () and Capget (). The Linux Security Module (LSM) also retains these system calls but replaces them with calls to the hook function so that it can be re-implemented basically through the security () system call. The Linux Security Module (LSM) has developed and migrated a considerable portion of the capabilities logic into a capabilities security module, but the kernel still retains many remnants of the original capabilities. These implementations minimize the impact of modifications to the Linux kernel and retain support for legacy applications that use capabilities, while satisfying the functional requirements of the design. To make the capabilities module completely independent later, the main steps left to do are to move the bit vectors to the appropriate security domain in the TASK_STRUCT structure and to reposition the system call interface.

Back to top of page

4. Interface Description: Hooks for kernel developers and security researchers

The value of the Linux Security Module (LSM) for kernel developers and security researchers is that the existing security enhancement systems can be ported to this framework using the interfaces they provide, which can be made available to users in the form of loadable kernel modules, or even a security module that fits their needs directly. The Linux Security Module (LSM) provides the interface is the hook, the initialization of the virtual function pointed to the implementation of the default UNIX super-user mechanism, the module writer must re-implement these hook functions to meet their own security policy. The following is a brief introduction to the hooks provided by the Linux Security Module (LSM), please refer to the source code, especially the definition of the security_operations structure in the Include/linux/security.h header file. As for how to write the security module according to the security policy, we can refer to the security module of Selinux,dte,lids and so on.

The first is the task hook, the Linux security Module (LSM) provides a series of task hooks that enable the security module to manage the security information of the process and control the operation of the process. The module can use the security domain in the TASK_STRUCT structure to maintain process security information; The task hooks provide hooks to control interprocess communication, such as Kill (), and hooks that control privileged operations on the current process, such as setuid () There are also hooks for fine-grained control of resource management operations, such as Setrlimit () and Nice ().

The next is the program loading hooks. Many security modules, including Linux Capabilities,selinux,dte, require the ability to change privileges when a new program executes. Therefore, the Linux security Module (LSM) provides a series of program load hooks that are used at key points in the execution of a execve () operation. The security domain in the LINUX_BINPRM structure allows the security module to maintain security information during the loading of the program; provides hooks to allow the security module to initialize security information and perform access control before loading the program, and also provides a hook to allow the module to update the task's security information after the new program has been successfully loaded A hook is also provided for State inheritance during program execution, such as confirming open file descriptors.

Again is the inter-process communication IPC Hook. The security module can use interprocess communication IPC Hooks to manage the security information of the system V IPC and to perform access control. The IPC object data structure shares a substructure kern_ipc_perm, and this substructure has only one pointer passed to the existing ipcperms () function for permission checking, so the Linux security module (LSM) joins a security domain in the shared substructure. To support security information for individual messages, the Linux security Module (LSM) also adds a security domain to the MSG_MSG structure. The Linux Security Module (LSM) inserts a hook into the existing ipcperms () function, allowing the security module to perform checks on each existing Linux IPC authority. Because such checks are not sufficient for some security modules, the Linux security Module (LSM) also inserts hooks into a single IPC operation. There are also hooks that support fine-grained access control for individual messages sent over the System V message queue.

Here is the file system hook. For file operations, three types of hooks are defined: File system hooks, inode node hooks, and file hooks. The Linux Security Module (LSM) adds a security domain to the corresponding three kernel data structures: super_block structure, inode structure, and file structure. The super Block file system hooks allow the security module to control operations on the entire file system, such as mount, Unload, and Statfs (). The Linux Security Module (LSM) retains this function by inserting hooks into the permission () function, but it also provides a number of other inode node hooks to fine-grained access control for a single inode node operation. Some of the file hooks allow security modules to perform additional checks on file operations such as read () and write (), as well as file hooks that allow secure module control to receive open file descriptors through the socket IPC; other file hooks like fcntl () and IOCTL () Such operations provide fine-grained access control.

Next is the network hook. Application-level access to the network uses a series of socket socket hooks to arbitrate, which basically covers all socket-based protocols. Because each active user socket socket has an INODE structure, no security domain is added to the socket structure or to the lower sock structure. The socket socket hook provides a general quorum for network access to the process, thereby significantly extending the kernel's Network access control framework (which is already handled by the Linux kernel firewall netfilter). For example, the SOCK_RCV_SKB hook allows a packet that enters the kernel to be queued to the corresponding user space before the socket socket is used for the purpose of quorum. In addition, the Linux Security Module (LSM) also implements fine-grained hooks for the Ipv4,unix domain, as well as the NetLink protocol, and may later implement hooks for other protocols. The network data is encapsulated in the form of packets in the SK_BUFF structure (socket socket buffer) Travel protocol stack, the Linux security Module (LSM) in the Sk_buff structure to add a security domain, so that the level of the packet through the network layer of data security information management, A series of sk_buff hooks are provided to maintain the entire life cycle of this security domain. Hardware and software network devices are encapsulated in a net_device structure, and a security domain is added to this structure to enable the maintenance of security information at the device level.

And finally the other hooks. The Linux Security Module (LSM) provides two other series of hooks: a module hook and a top-level system hook. The module hooks are used to control the creation, initialization, and kernel operation of the kernel module. System hooks are used to control system operations, such as setting host names, accessing I/O ports, and configuring process accounting. Although the Linux kernel now provides some support for these system operations by using the capability check, these checks are very different and do not provide any parameter information.

Back to top of page

5. Module Description: Ready-to-use security features for ordinary users

The value of the Linux Security Module (LSM) for ordinary users is that it provides a variety of security modules that the user chooses to load into the kernel to meet specific security features. The Linux Security Module (LSM) itself only provides mechanisms for enhancing access control policies, and individual security modules implement specific security policies. Here is a brief introduction to some of the security modules that have been implemented.

SELinux. This is an implementation of the Flask flexible access control system on Linux and provides type enhancement, role-based access control, and an optional multilevel security policy. SELinux was originally implemented as a kernel patch and has now been re-implemented as a security module using the Linux Security Module (LSM). SELinux can be used to restrict processes to minimum privileges, protect the integrity and confidentiality of processes and data, and support application security requirements.

DTE Linux. This is an implementation of domain and type enhancements on Linux. Like SELinux, DTE Linux was originally implemented as a kernel patch and has now been re-implemented as a security module using the Linux Security Module (LSM). When this security module is loaded into the kernel, the type is assigned to the object and the domain is assigned to the process. The DTE policy restricts access between domains and from domain to type.

Openwall Kernel patch for LSM porting. The Openwall Kernel patch provides a collection of security features to protect the system from attacks such as buffer overflow and temporary file contention. A security module is being developed to support a subset of the openwall patches.

POSIX.1E capabilities. The POSIX.1E capabilities logic already exists in the Linux kernel, but the Linux security module (LSM) divides this logic into a security module. Such modifications make it possible for unwanted users to omit this functionality from their kernel, and to make the development of capabilities logic more independent from kernel development.

Lids. This is a project initiated by Chinese Xiahuagang. Initially developed as an intrusion detection system, it evolved to use the access control system as a form of intrusion prevention by describing what files a given program can access to access control. Similarly, lids was originally implemented as a kernel patch with some management tools and is now re-implemented as a security module using the Linux Security Module (LSM).

There are, of course, the default classic super-user mechanism. This security module is the default for the Linux Security Module (LSM), which implements the traditional UNIX super User privilege mechanism.

Back to top of page

6. Instructions for use: Step by step

The Linux Security Module (LSM) is currently implemented as a Linux kernel patch and is released under the GPL license for free use by users.

First, the user can download the http://lsm.immunix.org/lsm_download.html to the Linux 2.4 stable version and the Linux 2.5 development version of the LSM patch, placed in a directory, such as directory/path/to/ linux-2.4.x, make the LSM patch work on the Linux kernel by executing the following command:

# cd/path/to/linux-2.4.x# Zcat/path/to/patch-2.4.x-lsm.gz | Patch-p1

The user can then Http://lsm.immunix.org/lsm_ The modules.html connects to the site that has implemented the security module, downloads the required security module, and loads the security module into the Linux kernel, so that the security policies that the user needs can work, thereby enhancing the security of the system. The installation method of the specific security module here is skipped, each security module will provide detailed installation documentation, users can refer to these files, such as the SELinux Security Module installation documentation in: http://www.nsa.gov/selinux/doc/ Readme.html, such as the Lids Security Module installation instructions file in: http://www.lids.org/install.html.

If you have background knowledge and development experience with Linux kernel and security, you want to write security modules according to the security policies you need. The source code of the Linux Security Module (LSM) and the sources of the existing security modules can be traced in http://lsm.immunix.org/lsm_bk.html to write their own security modules by reference to their implementation methods. This can also contribute to the development of the Linux Security Module (LSM) while satisfying its own security requirements, making it an early acceptance by the Linux kernel of the Linux kernel security mechanism and benefiting more users.

Back to top of page

7. Concluding remarks: Standards for the future

The cause of the Linux Security Module (LSM) is that, on the one hand, the existing security mechanism of the Linux kernel is not sufficient, and the existing security enhancement system is fighting each other and difficult to use. Linux Security Module (LSM) Better solve the problem: on the one hand, the patch is relatively small, the changes in the kernel source code has little impact, the load is not large, on the other hand, the existing security enhancement system provides a better interface support, and has a lot of good security modules can be used. The Linux Security Module (LSM) is still available as a Linux kernel patch, but it also provides a series of Linux 2.4 stable versions and Linux 2.5 development versions, and hopefully goes into the Linux 2.6 stable version. We look forward to that day: the Linux Security Module (LSM) is accepted by the Linux kernel as a standard for Linux kernel security, and is available to a growing number of users in various Linux distributions.