A permission control method, permission control device and computer storage medium

Abstract

The present application proposes a permission control method, permission control device, and computer storage medium. The permission control method includes: responding to a process's running instruction, running the process's program; reading an independent system call table corresponding to the program, wherein an independent system call table is generated for each process; and calling the kernel's system call interface based on the independent system call table to implement the process's business functions. Through the above permission control method, a minimized system call table is generated for each process, so that the process can only access the kernel through these system call interfaces known during the compilation phase, reducing the kernel's exposure and increasing the difficulty for hackers to attack.

Description

Technical Field

[0001] The present application relates to the technical field of operating system kernel design, and in particular to a permission control method, a permission control device, and a computer storage medium. Background Art

[0002] Existing process permission control is primarily based on user permissions. Root users have the highest permissions, while other users have limited permissions, resulting in "Permission denied" prompts when executing certain high-level commands. The legitimacy of an operation can be determined by factors such as file ownership, whether it has execute permissions, and whether certain operations require root permissions.

[0003] Although Linux's permission management is relatively mature, in actual use, hackers are still found to exploit certain vulnerabilities to elevate privileges, thereby obtaining the highest privileges of the target system and controlling the entire system, causing a great threat to the security of the kernel. Summary of the Invention

[0004] To solve the above technical problems, the present application proposes a permission control method, a permission control device and a computer storage medium.

[0005] To solve the above technical problems, this application proposes a permission control method, which includes:

[0006] In response to the execution instruction of the process, executing the program of the process;

[0007] Reading an independent system call table corresponding to the program, wherein an independent system call table is generated corresponding to each process;

[0008] The system call interface of the kernel is called based on the independent system call table to implement the business function of the process.

[0009] The step of reading the independent system call table corresponding to the program includes:

[0010] Reading a process control block corresponding to the program;

[0011] The independent system call table is obtained through the process control block.

[0012] The method of calling the kernel's system call interface based on the independent system call table includes:

[0013] Obtaining a function pointer from the independent system call table;

[0014] According to the physical address pointed to by the function pointer, the corresponding system call interface is called from the kernel.

[0015] The permission control method further includes:

[0016] In response to a compilation instruction of the process, obtaining a system call interface required by the process to implement a business function;

[0017] Based on the required system call interface, obtain the system call number and generate a system call number table;

[0018] The system call number table is written into the header of the program.

[0019] The permission control method further includes:

[0020] In response to a start instruction of the process, the independent system call table is generated based on the system call number table.

[0021] The independent system call table is stored in the process control block or independent memory space of the program.

[0022] Wherein, the independent system call table is a pointer array;

[0023] Wherein, the pointer array includes the sequence number of the system call interface required by the process and its function pointer;

[0024] Alternatively, the pointer array includes serial numbers of all system call interfaces and function pointers corresponding to the serial numbers of the system call interfaces required by the process, and the serial numbers of the system call interfaces not required by the process are recorded as null pointers.

[0025] The kernel address space opens up an independent mapping area for each process, and the independent mapping area for each process stores an independent system call table for each process;

[0026] The reading of the independent system call table corresponding to the program includes:

[0027] Extracting the logical address of the independent system call table in the kernel in the independent mapping area of the program;

[0028] Converting the logical address to a physical address of the kernel by a memory management unit of the kernel;

[0029] The physical memory of the kernel is accessed according to the physical address, and the independent system call table of the program is extracted.

[0030] To solve the above technical problems, the present application also proposes a permission control device, which includes a memory and a processor coupled to the memory; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the permission control method as described above.

[0031] In order to solve the above technical problems, the present application also proposes a computer storage medium, which is used to store program data. When the program data is executed by a computer, it is used to implement the above permission control method.

[0032] Compared to existing technologies, the present invention has the following advantages: the permission control device responds to a process's run instruction to run the process's program; reads the program's corresponding independent system call table, where each process generates an independent system call table; and calls the kernel's system call interface based on the independent system call table to implement the process's business functions. Through the permission control method described above, a minimized system call table is generated for each process, allowing the process to access the kernel only through these system call interfaces known during the compilation phase, reducing the kernel's exposure and increasing the difficulty of hacker attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without inventive efforts. Among them:

[0034] Figure 1 This is a flowchart of an embodiment of the permission control method provided by this application;

[0035] Figure 2 This is a schematic diagram of the overall process of system call tailoring in the compilation and runtime stages provided by this application;

[0036] Figure 3 This is a schematic diagram of a solution for making a system call through a process control block provided by this application;

[0037] Figure 4 yes Figure 1 The specific flow diagram of step S12 of the permission control method shown;

[0038] Figure 5 This is a schematic diagram of the process accessing the kernel scenario provided by this application;

[0039] Figure 6 This is a schematic diagram of the kernel address space provided by this application;

[0040] Figure 7 This is a schematic diagram of the page table pointer array provided by this application;

[0041] Figure 8 This is a schematic diagram of the memory allocation and release scenario provided by this application;

[0042] Figure 9 This is a flowchart of another embodiment of the permission control method provided by this application;

[0043] Figure 10 This is a structural diagram of an embodiment of the permission control device provided by this application;

[0044] Figure 11 It is a structural diagram of an embodiment of a computer storage medium provided by this application. DETAILED DESCRIPTION

[0045] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0046] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the application described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, method, product, or apparatus.

[0047] This application proposes a security enhancement solution based on system call tailoring. This approach fundamentally reduces the services provided by the kernel to a process, thereby limiting the possibility of hackers exploiting system call security to escape after potentially compromising the process. The operating system kernel design proposed in this application improves system security by tailoring system calls, shielding some unnecessary functions.

[0048] In traditional operating systems, the kernel maintains a system call table, which summarizes all interfaces exposed by the kernel to processes. Because the traditional kernel is shared by all processes, it exposes all system interfaces to each process, exposing the system's attack surface. However, since the number of system calls used by each process is limited, controllable, and known during the compilation phase, the compilation phase analyzes and counts the system calls a program will use. During process startup, differentiated system call interface exposure is performed based on this statistical information.

[0049] Please refer to the following for details: Figure 1 and Figure 2 , Figure 1 This is a flowchart of an embodiment of the permission control method provided by this application. Figure 2 This is a schematic diagram of the overall process of system call tailoring in the compilation stage and the running stage provided by this application.

[0050] like Figure 2 As shown, with the assistance of the compilation and execution stages, this application implements control over the system calls available to each process. Under normal circumstances, this application can fully determine which system calls the program will use when writing code, so it will not affect the normal execution of the program. However, once the program is injected into other execution processes due to a vulnerability attack, since we only expose a small number of system call interfaces for this specific business, the attacker has very little attack surface available, making it difficult to expand this attack to generate actual attack value. Therefore, the attacker can only limit the effect of the attack to this business and cannot affect the entire system.

[0051] The permission control method of the present application is applied to a permission control device, wherein the permission control device of the present application can be a server, a terminal device, or a system composed of a server and a terminal device. Accordingly, the various parts of the permission control device, such as the various units, subunits, modules, and submodules, can be all set in the server, all set in the terminal device, or separately set in the server and the terminal device.

[0052] Furthermore, the server described above may be either hardware or software. When the server is hardware, it may be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it may be implemented as multiple software programs or software modules, such as software or software modules for providing a distributed server, or as a single software program or software module, without further limitation.

[0053] like Figure 1 As shown, the specific steps are as follows:

[0054] Step S11: In response to the process execution instruction, the program of the process is executed.

[0055] In the embodiments of this application, Figure 2 In the running phase shown, in response to the running instruction of the target process, the permission control device runs the program of the process.

[0056] Step S12: Reading the independent system call table corresponding to the program, wherein an independent system call table is generated corresponding to each process.

[0057] In an embodiment of the present application, the permission control device reads the independent system call table of the target process in the kernel. The present application changes the system call table from one table per kernel to one table per process, thereby achieving an independent system call table generated for each process.

[0058] Among them, the independent system call table of each process only includes the system call interface required to implement the specific business of its own process, thereby ensuring that each process only exposes a small number of system call interfaces, which can provide greater protection for the kernel.

[0059] In a specific implementation scheme, when a system call occurs, the permission control device finds the data structure corresponding to the process, finds the system call table, and completes the system call according to the system call table.

[0060] Specifically, see Figure 3 , Figure 3 This is a schematic diagram of the scheme for making system calls through process control blocks provided by this application. In the kernel, process 1 has independent and shared data structures, such as Figure 3 The Process Control Block (PCB) 1 in the process is used to store the system call table unique to process 1. Figure 3 As can be seen, the independent system call table of PCB1 for process 1 includes the following system call interfaces: system call 1, system call 3, system call 6, system call 11, system call 16, etc.; while the independent system call table of PCB2 for process 2 includes the following system call interfaces: system call 1, system call 6, system call 9, system call 12, system call 15, etc. This comparison shows that each process's independent system call table need not record all interfaces provided by the system; it only needs to record the interfaces used to implement the functions required by the process's tasks. By limiting the number of interfaces exposed by the kernel to the process during execution, kernel space can be effectively protected.

[0061] Furthermore, a specific implementation form of the system call table of the present application is a function pointer array, which is expressed as follows:

[0062]

[0063] Another representation of the function pointer array of this application is as follows:

[0064]

[0065] For system call interfaces that are not needed by the process, the corresponding pointers are set to null pointers.

[0066] Each system call number has a corresponding function pointer, which represents the address mapping relationship pointing to the system call interface corresponding to the system call number. Therefore, the permission control device can search for the physical address of the system call interface in the kernel based on the virtual address of the system call table and the address mapping relationship in the function pointer, thereby completing the call to the system call interface.

[0067] Furthermore, since data structures such as the process control block may contain other information, such as process-related information, such as process ID, process status, process physical address, process scheduling information, etc. Therefore, in order to improve the efficiency of interface calls, the present application can also set pointers in fixed fields of the data structure, and search the specific location of the system call table in the process control block through the pointers. The search method using pointers is also applicable to system call tables of different sizes. Since the number of interfaces required to be called by each process may be different, the size of the system call table may also be different. Using the starting position and end position specified by the pointer can improve the search efficiency of the system call table.

[0068] In the implementation of the above solution, since each process can see the same kernel space, each process can still read the system call table of other processes and use the system call table of other processes to execute the corresponding system call.

[0069] Therefore, this application further proposes another implementation scheme, please refer to Figure 4 and Figure 5 , Figure 4 yes Figure 1 The specific flow diagram of step S12 of the permission control method is shown. Figure 5 This is a schematic diagram of the scenario of a process accessing the kernel provided by this application.

[0070] like Figure 4 As shown, the specific steps are as follows:

[0071] Step S121: In the independent mapping area of the program, extract the logical address of the independent system call table in the kernel.

[0072] In the embodiments of this application, Figure 5 As shown, this application opens up a separate mapping area for each process in the kernel address space, namely Figure 5An area for storing independent system call tables. This independent mapping area is characterized by the fact that, although the logical address is the same for each process, the physical address to which it is mapped is different. Therefore, the present application can uniformly store the system call table of each process after trimming it at the same address in this independent mapping area.

[0073] Step S122: Access the physical memory of the kernel according to the logical address and extract the independent system call table of the program.

[0074] In an embodiment of the present application, when a system call occurs, the present application directly initiates access to the system call table based on the logical address of the unified system call table. With the mapping assistance of the underlying MMU (Memory Management Unit), each process will automatically access its own system call table.

[0075] The MMU is responsible for translating virtual addresses into physical addresses. The MMU uses a translation table to map the virtual addresses used by programs to actual physical memory locations, enabling dynamic management and isolation of memory.

[0076] This solution is more complex to implement and modifies the kernel's address space mapping relationship, but it is more secure because, under the management of the MMU, a process cannot access the system call table of other processes, ensuring isolation. Secondly, since each process can directly access the system call table, there is no need to search in a bunch of data structures like the previous solution, so it is more efficient.

[0077] Furthermore, this application redesigns the address space model to add a kernel process independent mapping area to the kernel space. The address space within this area is different from other spaces. Each process not only has an independent address space, but also this part of the address space of each process is independently mapped to different physical memory, thus obtaining an independent process space for each process.

[0078] Please refer to the following for details: Figure 6 , Figure 6 This is a schematic diagram of the kernel address space provided by this application. Figure 6 As shown in the figure, since each process has an independent kernel mapping area, many original process-independent information can be stored more securely in the independent mapping area to avoid damage and tampering by other processes. However, in order for the kernel to quickly find the corresponding information when performing operations such as process scheduling and resource allocation, this application creates a process page table pointer array in the kernel direct mapping area, such as Figure 7 As shown, Figure 7This is a schematic diagram of the page table pointer array provided by this application. It records the page table pointer of each process. Through the page table pointer, the virtual address mapping relationship of each process can be quickly found. This allows for quick access to the relevant resources of the entire process.

[0079] For a kernel, the sizes of its direct mapping area and independent mapping area are essentially fixed, so the location that can be allocated to the independent mapping area is also essentially fixed. Therefore, all processes have the same independent mapping area offset. This fixed value allows the kernel to quickly locate the relevant variables in the kernel's independent mapping area for a specific process using the process's page table pointer when needed. For different kernels, this value can be adjusted based on the size of the common mapping area to suit different business scenarios.

[0080] In traditional kernels, the allocation and release of memory in the dynamic mapping area are completed by vmalloc and vfree. The mapping relationship of the allocated memory will be written to the main kernel page table. When other processes access it, if it is not found in the kernel area of the process page table, the latest main kernel page table will be automatically copied to complete the synchronization of the kernel page table.

[0081] And for Figure 6 As shown in the kernel space, first of all, due to the existence of independent mapping areas, its main kernel page table is not equivalent to the kernel area of each process page table. When synchronizing, only the non-independent mapping areas need to be synchronized. For details, please refer to Figure 8 , Figure 8 This is a schematic diagram of the memory allocation and release scenarios provided by this application. Independent mapping areas also require new allocation and release functions (imalloc, ifree). Unlike vmalloc, the address mapping of the allocated memory is only written to the independent mapping area of the corresponding process, thus maintaining the independence of the memory in this independent mapping area. When writing kernel modules, staff will determine whether to use imalloc or vmalloc based on the accessible range of the allocated memory.

[0082] The independent mapping area can store, for example, the process control block (PCB), process resource information, etc. At the same time, in a container environment, in order to further ensure isolation, the user group, mounted file system, and network information of each process can also be stored independently in an independent mapping area to avoid being accessed by other processes, and to prevent the process from accessing relevant information of other processes through kernel state, thereby causing container escape.

[0083] Step S13: calling the kernel's system call interface based on the independent system call table to implement the business functions of the process.

[0084] In an embodiment of the present application, the present application utilizes an independent system call table to call the kernel's system call interface, thereby realizing the business functions of the process.

[0085] In this application, a permission control device responds to a process's run instructions, runs the process's program, reads the program's corresponding independent system call table, where each process generates an independent system call table, and calls the kernel's system call interface based on the independent system call table to implement the process's business functions. Through the above permission control method, a minimized system call table is generated for each process, allowing the process to access the kernel only through these system call interfaces known during the compilation phase, reducing the kernel's exposure and increasing the difficulty of hacker attacks.

[0086] This application generates a minimized system call table for each process, so that the process can only access the kernel through these system calls known at the compilation stage, reducing the exposure of the kernel and increasing the difficulty for hackers to attack.

[0087] This application adds an independent mapping area to the kernel, so that each process has its own independent space in the kernel state, thereby facilitating the isolation of some kernel resources and improving system security.

[0088] Please continue reading Figure 2 and Figure 9 , Figure 9 This is a flowchart of another embodiment of the permission control method provided by this application.

[0089] like Figure 9 As shown, the specific steps are as follows:

[0090] Step S21: In response to the compilation instruction of the process, obtain the system call interface required by the process to implement the business function.

[0091] Step S22: Based on the required system call interface, obtain the system call number and generate a system call number table.

[0092] Step S23: Write the system call number table into the header of the program.

[0093] In the embodiment of the present application, during the compilation process, the permission control device analyzes the function of the process and collects the system call numbers of the required system interfaces, thereby generating an independent system call number table for each process and writing it into the header of the process program. It will be understood by those skilled in the art that in the above-mentioned method of the specific implementation, the order in which the steps are written does not mean a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0094] Furthermore, during the startup or loading phase of a process, the kernel generates an independent system call table for the program (process) based on the system call number table formed during the program compilation phase.

[0095] In order to implement the above-mentioned permission control method, this application also proposes a permission control device, please refer to Figure 10 , Figure 10 It is a structural diagram of an embodiment of the permission control device provided by this application.

[0096] The authority control device 400 of this embodiment includes a processor 41 , a memory 42 , an input / output device 43 , and a bus 44 .

[0097] The processor 41 , the memory 42 , and the input / output device 43 are respectively connected to the bus 44 . The memory 42 stores program data, and the processor 41 is used to execute the program data to implement the permission control method described in the above embodiment.

[0098] In the embodiments of the present application, the processor 41 may also be referred to as a CPU (Central Processing Unit). The processor 41 may be an integrated circuit chip with signal processing capabilities. The processor 41 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. A general-purpose processor may be a microprocessor, or the processor 41 may be any conventional processor.

[0099] This application also provides a computer storage medium, please continue to refer to Figure 11 , Figure 11 1 is a schematic diagram of the structure of an embodiment of a computer storage medium provided in the present application. The computer storage medium 600 stores a computer program 61. When the computer program 61 is executed by a processor, it is used to implement the permission control method of the above embodiment.

[0100] When the embodiments of the present application are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0101] The above description is only an implementation method of the present application and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the description and drawings of this application, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A permission control method, characterized in that: The permission control method includes: In response to the execution instruction of the process, executing the program of the process; Reading an independent system call table corresponding to the program, wherein an independent system call table is generated corresponding to each process; Calling the kernel's system call interface based on the independent system call table to implement the business function of the process; The permission control method further includes: In response to a compilation instruction of the process, obtaining a system call interface required by the process to implement a business function; Based on the required system call interface, obtain the system call number and generate a system call number table; Writing the system call number table into the header of the program; The permission control method further includes: In response to a start instruction of the process, the independent system call table is generated based on the system call number table.

2. The permission control method according to claim 1, characterized in that: The reading of the independent system call table corresponding to the program includes: Reading a process control block corresponding to the program; The independent system call table is obtained through the process control block.

3. The permission control method according to claim 2, characterized in that: The system call interface of calling the kernel based on the independent system call table includes: Obtaining a function pointer from the independent system call table; According to the physical address pointed to by the function pointer, the corresponding system call interface is called from the kernel.

4. The permission control method according to claim 1, wherein: The independent system call table is stored in the process control block or independent memory space of the program.

5. The permission control method according to claim 1 or 4, characterized in that: The independent system call table is a pointer array; Wherein, the pointer array includes the sequence number of the system call interface required by the process and its function pointer; Alternatively, the pointer array includes serial numbers of all system call interfaces and function pointers corresponding to the serial numbers of the system call interfaces required by the process, and the serial numbers of the system call interfaces not required by the process are recorded as null pointers.

6. The permission control method according to claim 4, characterized in that: The kernel address space opens up an independent mapping area for each process, and the independent mapping area for each process stores an independent system call table for each process; The reading of the independent system call table corresponding to the program includes: Extracting the logical address of the independent system call table in the kernel in the independent mapping area of the program; Converting the logical address to a physical address of the kernel by a memory management unit of the kernel; The physical memory of the kernel is accessed according to the physical address, and the independent system call table of the program is extracted.

7. A permission control device, characterized in that: The authority control device includes a memory and a processor coupled to the memory; The memory is used to store program data, and the processor is used to execute the program data to implement the permission control method according to any one of claims 1 to 6.

8. A computer storage medium, characterized in that The computer storage medium is used to store program data, and when the program data is executed by a computer, it is used to implement the permission control method according to any one of claims 1 to 6.

Images