How to enhance the security of Linux systems, Part 1: Linux Security Module (LSM) Introduction
content:
Related background introduction: Why is it a description of the design idea: You have to satisfy the way to implement the method: the modification interface of the Linux kernel Description: Hook module used by the kernel developer and security researcher Description: Presentation used by ordinary users Safety function specific method of use Description: "Step By Step" Conclusion: Future Standard Reference About Author Feedback Information
In the Linux area:
Tutorial Tools & Product Codes and Component Project Articles
Future Standard: General Safety Support Framework for Linux Kernel Zhao Liang (zhao_liang@myway.com) Master's degree in Computer System in Nanjing University July 2003
Linux Security Module (LSM) is a lightweight access control framework for the Linux kernel. This article describes the background, design ideas, implementation methods of Linux Security Modules (LSM); and explains how to use Linux Security Modules (LSM) to enhance the security of Linux systems: one side is the interface used by kernel developers and security researchers. On the other hand, it is a module for ordinary users, as well as specific methods. If the reader has a Linux kernel and security related background knowledge, it can help to understand this article; if not, you can read the three articles on the IBM DW listed in this article.
1. Related background introduction: Why is the Linux system in recent years, due to its excellent performance and stability, open source characteristics of flexibility and scalability, as well as low-cost cost, and is received by the computer industry and is received by the computer industry. application. However, in terms of security, the Linux kernel only provides classic UNIX autonomous access control (root user, user ID, mode security mechanism), and part of the Capabilities security mechanism in the POSIX.1 draft Posix.1, which supports the Linux system. The security is not sufficient, affecting the further development and broader applications of Linux systems. There are many security access control models and frameworks that have been studied and developed to enhance the security of Linux systems, relatively well-known secure enhanced Linux (SELINUX), Domain and Type Enhancements (DTE), and Linux Intrusion Detection System (LIDS )and many more. However, since there is no system to get the dominant position and enter the Linux kernel to become a standard; and these systems are mostly provided in a variety of different kernel patches, using these systems require compilation and custom kernel capabilities, for non-kernel development Experience ordinary users, it is difficult to obtain and use these systems. At the 2001 Linux core summit, the US National Security Agency (NSA) introduced their work about security linux (selinux), which is an implementation of Flask in Linux, the founder of the Linux kernel Linus Torvalds agreed that the Linux kernel did need a universal security access control framework, but he pointed out that it is best to support the method of loading the kernel module, which can support existing different secure access control systems. Therefore, the Linux Security Module (LSM) came into being. Linux Security Module (LSM) is a lightweight access control framework for the Linux kernel. It enables a variety of different security access control models to be implemented in the form of Linux to load the kernel module, and the user can load into the Linux kernel according to its requirements, which greatly improves the flexibility of Linux security access control mechanism. And ease of use. There are already many famous enhanced access control systems to be implemented on Linux Security Modules (LSM), including POSIX.1E Capabilities, Security LINUX, Domain, and Type Enhancement (DTE), and Linux Intrusion Detection System (LIDS) and many more. Although the current Linux Security Module (LSM) is still available as a Linux kernel patch, it provides a series of LINUX 2.4 stable versions of the series and Linux 2.5 development versions, and it is very hoping to enter Linux 2.6 stable version, and implement it. Objective: The LINUX kernel accepts standards that become the Linux kernel security mechanism, and is provided to the user in each Linux release. 2. Design Thought Introduction: It is necessary to satisfy the two aspects of the Linux Security Module (LSM) must be asked to meet the requirements of the two people: let people who don't need it as little as possible, it will be troublesome; And efficient features. The kernel developers represented by Linus TorvalDs have put forward three requirements for Linux Security Modules (LSM):
Really universal, when using a different security model, just load a different kernel module concept is simple, the Linux kernel affects the minimum, efficient, and supports existing POSIX.1E Capabilities logic, as an optional On the other hand, the requirements for various Linux security enhancements to Linux Security Modules (LSM) are: allowed to reinforce their security functions in the form of loadable kernel modules, and will not bring security. Come obvious losses, and will not bring additional system overhead. In order to meet these design objectives, the Linux Security Module (LSM) uses the method of placing hooks in the internal nuclear source code, to arbitrate access to kernel internal objects, these objects are: task, inode node, open file, etc. . User Process Performs a system call, first travel the original logic of Linux kernel to find and assign resources, perform error check, and pass the classic UNIX autonomous access control, just before the Linux kernel is accessed, one Linux security module ( The hook of the LSM is a call to the function that the security module must provide, so that the security module is proposed "whether access is permitted?", The security module makes a decision based on its security policy, make an answer: allow, or refuse to return a mistake. On the other hand, in order to meet the needs of most of the existing Linux security enhancements, the Linux Security Module (LSM) has adopted a simplified design decision. Linux Security Module (LSM) is now mainly supporting the core functions of most existing security enhancements: access control; other security features required for some security enhancements, such as security audits, only provide a small amount of support. Linux Security Module (LSM) Now, "Limited" access control decision: When the Linux kernel gives access, the Linux Security Module (LSM) may reject, and when the Linux kernel refuses to access, I will directly skip Linux security. Module (LSM); for the opposite "allowed" access control decision only provides a small amount of support. For module function synthesis, Linux Security Module (LSM) allows module stacks, but leaves the main work to the module itself: the final decision of module functionality by the first loaded module. All of these design decisions may temporarily affect the functionality and flexibility of Linux security module (LSM), but greatly reduce the complexity of Linux Security Module (LSM) implementation, reducing the modification and impact on Linux kernel, making it enters Linux kernel The possibility of becoming a safety mechanism is greatly improved; if it is standard, it can change decision, increase function and flexibility. 3. Implementation: Modifying Linux Security Modules (LSM) is currently implemented as a Linux kernel patch. Its itself does not provide any specific security strategy, but provides a general infrastructure to security modules, which implements specific security policies by security modules. It is mainly modified for the Linux kernel in five aspects:
In the specific kernel data structure, the security domain is added to the different key points in the kernel source code, inserted into a call to the security hook function Add a universal security system call to provide a function allows the kernel module to register as a security module or logout Capabilities. Most of the logic transplant into an optional security module to make a brief introduction to these five modifications. The security domain is a void * type pointer that allows the security module to link security information and kernel internal objects. The core data structure that is modified to have been modified, and the internal object of the respective represented:
Task_struct structure: Representative Task (Process) Linux_binprm Structure: Representative SUPER_BLOCK Structure: Representative File System Inode Structure: Represents Pipes, Files, or Socket Sockets File Structure: Open File SK_BUFF Structure: Represents Network Buffer (Pack) NET_DEVICE Structure: On behalf of the network device KERN_IPC_PERM structure: represents the Semaphore signal, shared memory segment, or message queue MSG_MSG: represents a single message additional, MSG_MSG structure, MSG_Queue structure, shmid_kernel structure is moved to include / Linux / msg.h and include / Linux / SHM.H In both header files, the security module can use these definitions. Linux Security Module (LSM) provides two types of calls to security hook functions: a type of security domain for managing kernel objects, and another type of arbitration to these kernel objects. The call to the security hook function is implemented by hooks. The hook is the function pointer in the global table security_Ops. The type of global table is the SECURITY_OPERATIONS structure. This structure is defined in the header file of include / Linux / security.h, this structure contains Subrostructure consisting of hooks in the kernel object or kernel subsystem, and some top hooks for system operation. It is easy to find a call to the hook function in the kernel source code: its prefix is security_ops->. The detailed description of the hook function is left behind. Linux Security Module (LSM) provides a universal security system call, allowing security modules to write new system calls for security-related applications, and its style is similar to the original Linux system call socketcall (), is a multi-channel system call. . This system calls to security (), its parameters (unsigned int ID, unsigned int call, unsigned long * args), where ID represents the module descriptor, Call represents call descriptors, and args represents a list of parameters. This system calls the default providing a sys_security () entry function: It is simple to call the SYS_SECURITY () hook function with parameters. 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 this system call. During the kernel boot, the Linux Security Module (LSM) frame is initialized to a series of virtual hook functions to achieve traditional UNIX super user mechanisms. When loading a security module, you must register this security module using the register_security () function to the Linux Security Module (LSM) frame: This function will set the global table security_OPS to point to the hook function pointer of this security module, so that the kernel is to this Security modules inquire about access control decisions. Once a security module is loaded, it becomes the system's security policy decision center, not by the rear register_security () function, until this security module is used to log out to the frame: This is simple to replace the hook function to Default, the system returns to the UNIX super user mechanism.
In addition, the Linux Security Module (LSM) framework also provides functions mod_reg_security () and function mod_unreg_security (), so that the subsequent security module can register and log out to the first registered primary module, but its policy implementation is determined by the main module : Yes provide some strategy to implement module stacks to support module function synthesis, or return the error value to ignore its subsequent security modules. These functions provide in the kernel source code file security / security.c. The Linux kernel is now supported by a subset of POSIX.1E Capabilities. One requirement for the Linux Security Module (LSM) design is to transplant this function as an optional security module. POSIX.1E Capabilities provides a feature that divides traditional superuser privileges and assigning a specific process. The Linux Security Module (LSM) retains the existing Capable () interface used to perform Capability inspections in the kernel, but simplifies the Capable () function into a package of Linux Security Module (LSM) hook function, allowing in the security module. Implement any logic required. The Linux Security Module (LSM) also retains the process Capability set in the Task_STRUCK structure (a simple bit vector), and does not move it to the security domain. Linux kernel supports Capabilities also includes two system calls: capSet () and CapGet (). The Linux Security Module (LSM) also retains these system calls but replaces them to the call to the hook function, so that it can basically be re-implemented by the security () system call. Linux Security Module (LSM) has been developed and transplanted with a considerable part of the Capabilities logic to a Capabilities security module, but the kernel still retains a lot of residues of Capabilities. These implementations reduce the impact on the revision of the Linux kernel, and the maximum extent is kept support for the original application of Capabilities while meeting the design of the design. In the future, the Capabilities module will be completely independent, and the remaining main step is to move the bit vector to the appropriate security domain in the Task_struct structure, and reposition the system call interface. 4. Interface Description: The value of the hook Linux Security Module (LSM) used to kernel developers and security researchers is that the value of kernel developers and security researchers is that the existing security enhancements can be transplanted to this framework using their interfaces. On, it is possible to provide the user in the form of the loadable kernel module; or even directly write security modules suitable for yourself. The interface provided by the Linux Security Module (LSM) is a hook. The virtual function pointed to by the initialization implements the default traditional UNIX super user mechanism, and the module writer must re-implement these hook functions to meet their own security policies. The following is a brief introduction to the hooks provided by the Linux Security Module (LSM). For details, please refer to the source code, especially the definition of the Security_Operations structure in the include / linux / security.h header. As for how to write security modules according to the security policy you need, you can refer to the security module of SELINUX, DTE, LIDS and other systems. The first is the task hook, the Linux Security Module (LSM) provides a series of task hooks 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; task hooks provide hooks that control inter-process communication, such as kill (); also provides hooks that control the privilege operation of the current process, such as setuid (); A hook controlled to resource management operations, such as Strlimit () and Nice (). Secondly, the program is loaded with hooks. Many security modules, including Linux Capabilities, SELINUX, DTE requires the ability to change privileges when a new program is executed. Therefore, the Linux Security Module (LSM) provides a series of programs to load hooks, with a critical point in an execve () operation process. The security domain in the Linux_binPRM structure allows the security module to maintain security information during the program loading process; provide hooks to allow security modules to initialize security information and perform access control before loading programs; also provides hook allow modules to be successfully loaded in new programs Update the security information of the task; also provides the hook used to control the status inheritance during execution, such as confirming the file descriptor opened. Once again, there are inter-process communication IPC hooks. Security modules can use inter-process communication IPC hooks to manage SYSTEM V IPC security information, and perform access control. The IPC object data structure shares a sub-structure kern_ipc_perm, and only one pointer is transmitted to the existing IPCPERMS () function permission check in this sub-structure, so the Linux Security Module (LSM) joins a security domain in this shared sub-structure. In order to support the security information of a single message, the Linux Security Module (LSM) has also added a security domain in the MSG_MSG structure. Linux Security Module (LSM) Insert a hook in an existing IPCPerms () function, allowing security modules to perform checks for each existing Linux IPC permission. Since certain security modules, such inspections are not sufficient, the Linux Security Module (LSM) is also inserted into the hook in a single IPC operation. In addition, hook supports access control of fine-grained access to a single message sent by the System V message queue. Here is the file system hook. For file operations, three hooks are defined: file system hooks, inode node hooks, and file hooks. The Linux Security Module (LSM) joins the security domain in the corresponding three kernel data structures, namely the Super_Block structure, an Inode structure, and a File structure. Super block file system hook enables security modules to control operations for the entire file system, such as mount, unloading, and statfs (). Linux Security Module (LSM) Inserts the hook in the Permission () function, reserved this function, but also provides a lot of other inode node hooks to perform fine-grained access control for a single Inode node operation. Some of the document hooks allow security modules to make additional checks for file operations such as read () and write (); and file hook allows security modules to control open file descriptors via Socket IPC; other file hooks Of FCNTL ) And IOCTL () operations provide fine-grained access control. Next is a network hook. Access to the application layer of the network uses a series of Socket socket hooks for arbitration, which basically covers all Socket socket protocols. Since each activated user socket socket is accompanied by an inode structure, there is no security domain in the Socket structure or a more underlying SOCK structure.
The Socket Socket Hook provides a general arbitration for network access to the process, thereby significantly expanding the network access control framework of the kernel (which is processed by the Linux kernel firewall Netfilter). For example, the SOCK_RCV_SKB hook allows for arbitration to the application of its purpose before entering the kernel's package queue to the corresponding user space Socket socket. In addition, the Linux Security Module (LSM) is also an IPv4, UNIX domain, and the NetLink protocol implements fine-grained hooks, which may also implement hooks of other protocols. Network data is packaged in the form of a package in the SK_BUFF structure (Socket Socket Cooling Area), the Linux Security Module (LSM) adds a security domain in the SK_BUFF structure, enabling the network over the network The security information of the data is managed and provides a range of SK_Buff hooks to maintain the entire lifecycle of this security domain. Hardware and software network devices are encapsulated in a NET_DEVICE structure, and one security domain is added to this structure so that security information can be maintained at the level of the device. Finally, there are other hooks. Linux Security Module (LSM) provides two other series of hooks: module hooks and top-level system hooks. The module hook is used to control the kernel operation of creation, initialization, and clear the kernel module. System hooks are used to control system operations, such as setting host names, access I / O ports, and configuring process bills. While the current Linux kernel provides some support for these system operations by using Capability, these checks are large for different operations and have no parameter information. 5. Module Description: The existing security function for ordinary users Linux security module (LSM) for ordinary users is: Various security modules can be provided, and the user chooses to be loaded into the kernel to meet specific security functions. Linux Security Module (LSM) itself provides only a mechanism to enhance access control policies, while each security module implements a specific security policy. The following is a brief introduction to some security modules that have been implemented. Selinux. This is an implementation of a Flask flexible access control system on Linux and provides type enhancement, role-based access control, and optional multi-level security policies. SELINUX is originally implemented as a kernel patch, and now I have reached a security module using the Linux Security Module (LSM). SELinux can be used to limit the process as minimum privilege, protection process and data integrity and confidentiality, and support application security requirements. DTE Linux. This is an implementation of a domain and type enhanced in Linux. Just like SELINUX, DTE Linux is originally implemented as a kernel patch, and now I have re-implemented 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. DTE policy limits the domain and access from domain to type. Openwall kernel patch LSM transplantation. The OpenWall kernel patch provides a range of security characteristics to protect the system from attacks such as buffer overflow and temporary file competition. A security module is being developed to support a subset of the OpenWall patch. Posix.1e capabilities. There is already a POSIX.1E Capabilities logic in the Linux core, but the Linux Security Module (LSM) divides this logic to a security module. Such modifications make unwanted users can slightly remove this function from their kernel; also enabled Capabilities logic to get greater independence from core development. LIDS.
This is the project of Chinese Xie Huang Gang. At the beginning, it is developed as an intrusion detection system, which will gradually evolve into the form of an access control system to perform intrusion prevention, which can access which files can be accessed by describing a given program. Similarly, LIDS is originally implemented as a kernel patterner and has some management tools, and now I have reached a security module using the Linux Security Module (LSM). Of course, there is a default traditional super user mechanism. This security module is the Linux Security Module (LSM) default, which implements traditional UNIX superuser privileges. 6. Specific use Method Description: Step By Steplinux Security Module (LSM) is currently implemented as a Linux kernel patch, which is released freely in the GPL license. First of all, users can download to the LSM patch corresponding to Linux 2.4 stability and Linux 2.5 development version in http://lsm.immunix.org/lsm_download.html, put in a directory / path / to / linux -2.4.x, make the LSM patch on the Linux kernel by performing 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 connect to the site of the security module that has implemented the security module at http://lsm.immunix.org/lsm_modules.html, download the security module to the Linux kernel, so that the security policy required by the user is It can work, thereby enhancing the security of the system. The installation method of the specific security module is slightly over, each security module provides detailed installation instruction file, and the user can refer to these files, such as SELinux security module installation instructions in: http://www.nsa.gov/selinux /Doc/readme.html, an additional secure module installation instruction file such as LIDS in: http://www.lids.org/install.html. If the user has a Linux kernel and security related background knowledge and development experience, we want to write security modules according to the security policy they need. You can track your own security module for the source code of the Linux Security Module (LSM) and the source code of the existing security module. In this way, while satisfying its own safety needs, some contributions can also be made for the development of Linux Security Modules (LSM), so that they will receive standards for Linux kernel security mechanisms as soon as possible, so that more users have benefited. 7. Conclusion: The cause of the future Standard Linux Security Module (LSM) is: On the one hand, the LINUX kernel existing security mechanism is not enough; on the other hand, the existing security enhancement system is also fighting and difficult to use. Linux Security Module (LSM) is better to solve this problem: on the one hand, the patch is relatively small, there is not much impact on the modification of the kernel source code, the load is not large; on the other hand, the existing security enhancement system is provided. Comparable interface support and have a lot of good security modules. Linux Security Module (LSM) is still available as a Linux kernel patch, but it provides a series of LINUX 2.4 stable versions of the series and Linux 2.5 development versions, and it is very hoping to enter Linux 2.6 stable versions. We look forward to that day: Linux Security Module (LSM) is received by the Linux kernel to become a standard for Linux kernel security mechanisms, providing more and more users in each Linux release. Reference
The main site of Linux Security Module (LSM) is: http: //lsm.immunix.org/ Linux Security Module (LSM) source code management site in: http://lsm.bkbits.net/ Linux kernel's primary site : Http://www.kernel.org/Hard Soft Software for Security Linux (SELINUX) At: http://www.nsa.gov/Selinux/ Domain and Type Enhancement (DTE) primary site: http: // Www.cs.wm.edu/~hallyn/dte/ Linux Intrusion Detection System (LIDS) Main site in: http://www.lids.org/ Linux kernel firewall Netfilter / iptables main site: http: // Www.netfilter.org/ If the reader does not have a Linux kernel and security related background knowledge, you can read these three articles on developerWorks first: "Unveil the secret of SE Linux": http://www-900.ibm.com /Developerworks/cn/linux/s-selinux/index.shtml, http://www-900.ibm.com/developerWorks/cn/linux/s-selinux2/index.shtml "Forced access control mechanism in FreeBSD 5.0 Analysis with source code ": http://www-900.ibm.com/developerWorks/cn/security/se-fbsdsec/part1/index.shtml, http://www-900.ibm.com/developerWorks/cn/cn/ Security / SE-fbsdsec / part2 / index.shtml "Netfilter: Linux firewall implementation in the kernel": http://www-900.ibm.com/developerworks/cn/linux/network/L- Netip/index.shtml About the author of Zhao Liang, Master of Computer Science, Nanjing University, Research Direction: Safety Operating System. Email: zhao_liang@myway.com, welcome to discuss Linux kernel and security related issues.
