A system call validity verification method and system for an operating system

Abstract

This invention relates to a method and system for validating the legitimacy of system calls in an operating system, belonging to the field of system call technology. It addresses the problem that existing security solutions lack universality for specific vulnerabilities or domains. The method includes: implementing an LSM security module in kernel space based on the LSM framework, using inode nodes as the arbitration object; configuring corresponding security policies for different applications in user space using seccomp-bpf; injecting the security policies into the security domain of the inode node corresponding to the application in the LSM security module; intercepting the application's process-initiated system calls; loading the security policies stored in the security domain of the application's inode node into the process space; and validating the process's system calls according to the security policies. This achieves fine-grained control of the operating system over the system call interfaces of all secure applications, improving the universality and efficiency of system call legitimacy verification.

Description

Technical Field

[0001] This invention relates to the field of system call technology, and in particular to a method and system for validating the legality of system calls in an operating system. Background Technology

[0002] In the Linux operating system, the kernel provides a set of interfaces for user processes to interact with the kernel. These interfaces allow applications to access hardware devices in a restricted manner, provide mechanisms for creating new processes and communicating with existing processes, and offer the ability to request other operating system resources. These interfaces act as messengers between applications and the kernel; applications issue various requests, and the kernel is responsible for fulfilling these requests (or returning an error if it cannot be fulfilled). In practice, providing these interfaces is primarily to ensure system stability and reliability, preventing applications from acting arbitrarily. However, in the operating system, a large number of system call interfaces are directly exposed to applications, potentially increasing the system's attack surface. However, not all system calls are necessary, and insecure code abusing system calls can pose security threats to the system.

[0003] As system call attacks have become a common technique used by hackers, many solutions have been proposed to address them, such as "Linux System Call Hijacking: Technical Principles, Applications and Detection", "Container Security Protection Scheme Based on System Call Restriction", and Android systems reducing the exposure of system calls by restricting the use of some system calls, etc. There are many such solutions. Some of these security solutions are aimed at a specific vulnerability in the system or a specific field, such as the container security field in the literature, and are not universal. Summary of the Invention

[0004] Based on the above analysis, the embodiments of the present invention aim to provide a method and system for verifying the legality of system calls in an operating system, in order to solve the problem that existing security solutions are not universally applicable to a specific vulnerability or a specific domain.

[0005] On one hand, embodiments of the present invention provide a method for validating the legality of system calls in an operating system, comprising the following steps:

[0006] An LSM security module is implemented in kernel space based on the LSM framework, using inode nodes as the arbitration object.

[0007] seccomp-bpf is used to configure corresponding security policies for different applications in user space;

[0008] Inject the security policy into the security domain of the inode node corresponding to the application in the LSM security module;

[0009] The system calls that the application starts are intercepted, the security policy stored in the security domain of the inode node corresponding to the application is loaded into the process space, and the system calls of the process are verified according to the security policy.

[0010] Based on further improvements to the above technical solution, the LSM security module implements the inode_alloc_security and inode_init_security hook functions;

[0011] The inode_alloc_security hook function is used to request and allocate inode security domains for the created inode nodes when the operating system starts and creates inode nodes for newly created files.

[0012] The inode_init_security hook function is used to initialize the inode security domain.

[0013] Furthermore, the security policy is injected into the security domain of the inode node corresponding to the application in the LSM security module, including:

[0014] The security policy is injected into the kernel space through the system call setxattr(const char*path,const char*name,const void*value,size_t size,int flags). The parameter path represents the path of the application executable file, the parameter name represents the identifier of the LSM security module, the parameter value represents the security policy, the parameter size represents the size of the security policy, and the flags is the default value.

[0015] The LSM security module also implements the inode_setxattr hook function, which is used to intercept the setxattr system call, find the inode node corresponding to the application in the LSM security module according to the path and name parameters of the setxattr system call, and store the security policy in the security domain of the inode node.

[0016] Furthermore, the LSM security module also implements the bprm_set_creds hook function, which is used to intercept the process startup system call of the application, find the inode node of the application according to the parameters of the process startup system call, extract the security policy from the inode node, and store the security policy in the process space of the process.

[0017] Furthermore, the security policy is stored in the seccomp field of the task structure of the process.

[0018] On the other hand, embodiments of the present invention provide a system call legality verification system for an operating system, comprising the following modules:

[0019] The LSM security module is a security module implemented in kernel space based on the LSM framework, with inode nodes as the arbitration object.

[0020] The security policy configuration module is used to configure corresponding security policies for different applications in user space using seccomp-bpf.

[0021] The security policy injection module is used to inject security policies into the security domain of the inode node corresponding to the application in the LSM security module.

[0022] The system call verification module is used to intercept the process startup system calls of the application, load the security policy stored in the security domain of the inode node corresponding to the application into the process space, and verify the process's system calls according to the security policy.

[0023] Based on further improvements to the above technical solution, the LSM security module implements the inode_alloc_security and inode_init_security hook functions;

[0024] The inode_alloc_security hook function is used to request and allocate inode security domains for the created inode nodes when the operating system starts and creates inode nodes for newly created files.

[0025] The inode_init_security hook function is used to initialize the inode security domain.

[0026] Furthermore, the security policy injection module injects the security policy into the kernel space through the system call setxattr(const char*path,const char*name,const void*value,size_t size,int flags); where the parameter path represents the path of the application executable file, the parameter name represents the identifier of the LSM security module, the parameter value represents the security policy, the parameter size represents the size of the security policy, and flags is the default value;

[0027] The LSM security module also implements the inode_setxattr hook function, which is used to intercept the setxattr system call, find the inode node corresponding to the application in the LSM security module according to the path and name parameters of the setxattr system call, and store the security policy in the security domain of the inode node.

[0028] Furthermore, the LSM security module also implements the bprm_set_creds hook function, which is used to intercept the process startup system call of the application, find the inode node of the application according to the parameters of the process startup system call, extract the security policy from the inode node, and store the security policy in the process space of the process.

[0029] Furthermore, the LSM security module stores the security policy in the seccomp field of the process's task structure.

[0030] Compared to existing technologies, this invention manages all processes in the system by implementing an LSM security module in kernel space based on the LSM framework, using inode nodes as the arbitration object. It employs seccomp-BPF to configure corresponding security policies for different applications in user space. By injecting these security policies into the security domain of the inode node corresponding to the application within the LSM security module, when different applications start, the security policy stored in the security domain of the application's corresponding inode node is looked up and loaded into the process space. Seccomp technology then verifies the application's system calls, enabling fine-grained control of system interface calls from all installed applications by the operating system. Due to the flexibility and efficiency of BPF, this invention boasts high code execution efficiency and allows for flexible policy formulation to meet the diverse verification needs of different applications. The system call legitimacy verification method of this invention has no application limitations; it can be used on any Linux kernel supporting the LSM security framework and Seccomp BPF, thus broadening its application scope. Furthermore, it allows for the customization of corresponding security policies for any application in the operating system to implement system call legitimacy verification.

[0031] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0032] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0033] Figure 1 This is a flowchart of the system call legality verification method for the operating system according to an embodiment of the present invention;

[0034] Figure 2 This is a block diagram of the system call legality verification system of the operating system according to an embodiment of the present invention. Detailed Implementation

[0035] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0036] Although the Linux kernel restricts the scope of system call access through access control mechanisms such as permissions and user types, the operating system still faces the following security threats:

[0037] By using techniques to escalate user privileges, ordinary users can access system call interfaces beyond their normal user permissions, increasing the risk of unauthorized access to system resources. Many system call hijacking attacks exploit this vulnerability.

[0038] Malicious programs frequently call system interfaces. System calls use interrupts to switch between user space and kernel space. Frequent system call interrupts can cause processes to continuously occupy CPU resources, making them unable to respond to other requests. In severe cases, this can lead to CPU resource exhaustion and system crashes.

[0039] The operating system kernel provides a large number of system call interfaces, which increases the system attack surface. For example, there are about 400 system call interfaces on the ARM / x86 platform.

[0040] As system call attacks have become a common technique used by hackers, many solutions have been proposed to address them. However, some existing security solutions are designed for specific vulnerabilities in the system or for specific domains, such as container security, and therefore lack general applicability.

[0041] Based on this, a specific embodiment of the present invention discloses a method for validating the legality of system calls in an operating system, such as... Figure 1 As shown, it includes the following steps:

[0042] S1. Implement an LSM security module in kernel space based on the LSM framework, using inode nodes as the arbitration object;

[0043] S2. Use seccomp-bpf to configure corresponding security policies for different applications in user space;

[0044] S3. Inject the security policy into the security domain of the inode node corresponding to the application in the LSM security module;

[0045] S4. Intercept the application's process startup system call, load the security policy stored in the security domain of the application's corresponding inode node into the process space, and verify the process's system call according to the security policy.

[0046] This invention is based on Linux seccomp (Secure Computing mode) technology and the kernel LSM (Linux Security Module) access control framework. Seccomp technology is primarily used to restrict the system calls available to a process. It's a mechanism to reduce the exposure of the Linux kernel and is currently mainly used to add BPF instructions to an application for filtering system calls. However, since BPF instructions are added during application development, they cannot be added to the application by a third party, and the operating system cannot interfere with the application's system interface calls, thus having significant limitations. LSM, on the other hand, is a lightweight, versatile security framework that can integrate different access control mechanisms.

[0047] This invention manages all processes in the system by implementing an LSM security module in kernel space based on the LSM framework, using inode nodes as the arbitration object. It employs seccomp-BPF to configure corresponding security policies for different applications in user space. By injecting these security policies into the security domain of the inode node corresponding to the application within the LSM security module, when different applications start, the security policy stored in the security domain of the application's corresponding inode node is looked up and loaded into the process space. Seccomp technology then verifies the application's system calls, enabling fine-grained control of system interface calls from all installed applications by the operating system. Due to the flexibility and efficiency of BPF, the code execution efficiency of this invention is high, and policies can be flexibly formulated to meet the different verification needs of different applications. This system call legitimacy verification method has no application limitations; it can be used on any Linux kernel that supports the LSM security framework and Seccomp BPF, thus broadening its application scope. Furthermore, it allows for the customization of corresponding security policies for any application in the operating system to implement system call legitimacy verification.

[0048] LSM, implemented as a Linux kernel patch, does not provide any specific security policies itself. Instead, it provides a general framework for security modules, which then implement their specific security policies. The LSM framework extends kernel functionality based on a hook mechanism. Its designers have listed almost every potential security vulnerability and inserted hooks in these locations. These hooks are defined as callback functions, and specific security modules only need to implement these hook functions themselves. Security modules arbitrate access to internal kernel objects, such as tasks, inodes, open files, semaphores, and messages, through hook methods placed in the kernel source code. The Linux kernel can support multiple different security modules simultaneously.

[0049] The LSM framework adds security fields to specific kernel data structures. A security field is a pointer of type void*, which allows the security module to associate security information with internal kernel objects. The following lists the kernel data structures that have been modified to include security fields, and the internal kernel objects they represent:

[0050] The `task_struct` structure represents a task (process);

[0051] The linux_binprm structure represents a program;

[0052] The super_block structure represents the file system.

[0053] inode structure: represents a pipe, file, or socket;

[0054] The file structure represents an open file;

[0055] The sk_buff structure represents a network buffer (packets);

[0056] The net_device structure represents a network device.

[0057] The kern_ipc_perm structure represents a Semaphore signal, a shared memory segment, or a message queue.

[0058] msg_msg: Represents a single message.

[0059] Since each application corresponds to a physical file (i.e., the binary file of its executable program), and each file has a corresponding inode data structure in the kernel, i.e., an inode node, the LSM security module of this invention uses the inode node as the arbitration object to implement hook functions related to the inode object.

[0060] The LSM security module implements the inode_alloc_security and inode_init_security hook functions;

[0061] The inode_alloc_security hook function is used to request and allocate inode security domains for newly created inode nodes when the operating system starts and creates inode nodes for newly created files.

[0062] The inode_init_security hook function is used to initialize the inode security domain.

[0063] When the operating system starts, it creates the files corresponding to the applications. When the open() or creat() system call is called to create a file, an inode is created for the new file. Taking the ext4 file system as an example, when the ext4_new_inode() function is called to create an inode for a new file in the ext4 file system, the inode_alloc_security hook function of the LSM security module intercepts the inode creation system call, requests and allocates the inode security domain.

[0064] Specifically, the data structure corresponding to the inode node has an i_security field, which is the security domain space. It is of type void*. The inode_alloc_security hook function of the LSM security module is used to specify the specific security data structure for i_security.

[0065] Specifically, in this invention, the security data structure of the LSM security module is as follows:

[0066] struct syscall_inode_security_struct{

[0067] void*fprog;

[0068] };

[0069] The fprog pointer points to the address of the security policy data, and the application's security policy is stored in this structure.

[0070] During implementation, a pointer of type syscall_inode_security_struct is assigned to i_security.

[0071] After inode_alloc_security is executed, the inode_init_security hook function is executed to initialize the inode security domain, for example, by initializing the i_security pointer to NULL.

[0072] During implementation, the security module implements the following hooks:

[0073] static struct security_hook_list hooks[]={

[0074] LSM_HOOK_INIT(bprm_set_creds,syscall_bprm_set_creds),

[0075] LSM_HOOK_INIT(inode_alloc_security,syscall_inode_alloc_security),

[0076] LSM_HOOK_INIT(inode_init_security,syscall_inode_init_security),

[0077] LSM_HOOK_INIT(inode_setattr,syscall_inode_setattr),

[0078] LSM_HOOK_INIT(inode_setxattr,syscall_inode_setxattr),

[0079] LSM_HOOK_INIT(inode_post_setxattr,syscall_inode_post_setxattr),

[0080] LSM_HOOK_INIT(inode_free_security,syscall_inode_free_security)

[0081] };

[0082] For example, the LSM security module implements the inode_alloc_security hook function, which uses the syscall_inode_alloc_security function to request and allocate inode security domains for inode nodes.

[0083] The implemented hook functions are added to the security_hook_list using the security_add_hooks(hooks, ARRAY_SIZE(hooks)).

[0084] Register the LSM security module to the LSM framework. Different kernel versions use different registration methods. For example, the LSM security module can be registered to the LSM framework using the `register_security` function, or it can be registered by initializing the LSM security module using the `DEFINE_LSM` macro.

[0085] For example, part of the initialization code for the LSM security module is as follows:

[0086] DEFINE_LSM(syscall) = {

[0087] .name = "syscall",

[0088] .flags=LSM_FLAG_LEGACY_MAJOR,

[0089] .enabled = &syscall_enabled,

[0090] .blobs=&syscall_blob_sizes,

[0091] .init = secsyscall_init,

[0092] };

[0093] In the secsyscall_init initialization module, security_add_hooks is called to add the hook functions implemented by the LSM security module to the security_hook_list.

[0094] During implementation, system call security policies can be customized for each application or type of application in the operating system user space according to the needs of the actual application scenario. The security policies are written using seccomp-bpf instruction rules.

[0095] For example, if an application requires write protection to the file system, a security policy can be written using BPF instructions to disable the use of the `write` system call interface. Specifically, the instruction code for disabling the `write` system call interface is as follows:

[0096] struct sock_app_filter filter[]={

[0097] BPF_STMT(BPF_LD+BPF_W+BPF_ABS,arch_nr),

[0098] BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K,ARCH_NR,1,0),

[0099] BPF_STMT(BPF_RET+BPF_K,SECCOMP_RET_KILL),

[0100] BPF_STMT(BPF_LD+BPF_W+BPF_ABS,syscall_nr),

[0101] BPF_JUMP(BPF_JUMP+BPF_JEQ+BPF_K,__NR_write,0,1),

[0102] BPF_STMT(BPF_RET+BPF_K,SECCOMP_RET_KILL)

[0103] }

[0104] The above is the C language implementation of the security policy for this application. The struct sock_app_filter array is used to store the security policy for this application.

[0105] The security strategy of this invention is not written into the application during the application development stage, but is written into the operating system kernel through a third party, thereby enabling the customization of corresponding security strategies for any application according to actual needs.

[0106] After configuring the corresponding security policies for each application or type of application that needs to be monitored, the security policies are injected into the security domain of the inode node corresponding to the application in the LSM security module. Specifically, this includes:

[0107] The security policy is injected into the kernel space through the system call setxattr(const char*path,const char*name,const void*value,size_t size,int flags). The parameter path represents the path of the application executable file, the parameter name represents the identifier of the LSM security module, the parameter value represents the security policy, the parameter size represents the size of the security policy, and the flags is the default value.

[0108] The LSM security module also implements the inode_setxattr hook function, which is used to intercept the setxattr system call, find the inode node corresponding to the application in the LSM security module according to the path and name parameters of the setxattr system call, and store the security policy in the security domain of the inode node.

[0109] Since the security policy is written in user space, it needs to be injected into kernel space. Specifically, the security policy is injected into kernel space through the `setxattr` system call. During implementation, the application file path is used as the `path` parameter, the LSM security module identifier as the `name` parameter, the application's security policy as the `value` parameter, the size of the application's security policy as the `size` parameter, and the `flags` parameter of `setxattr` has a default value of zero. The `setxattr` system call is then invoked.

[0110] In kernel space, the `setxattr` system call needs to be intercepted to preserve security policies. Therefore, the LSM security module also implements the `inode_setxattr` hook function to intercept the `setxattr` system call.

[0111] The security module also implements the following inode_setxattr hook function:

[0112] static int syscall_inode_setxattr(struct dentry*dentry,const char*name,const void*value,size_t size,int flags);

[0113] The inode pointer can be obtained through the parameter dentry(dentry->d_inode;). The security domain space can be found through the i_security field of the inode pointer. The value parameter passes the security policy. The data of value is copied to the i_security field of the inode node, thereby injecting the security policy into the kernel and storing it in the security domain of the inode corresponding to the application.

[0114] It should be noted that the setxattr system call takes the path file path as input at the user level. In kernel mode, the path path is converted into a struct dentry. This struct describes the logical attributes of the file. The dentry struct contains information such as the file name and the file's inode number.

[0115] When the application process starts, the system call to start the application process is intercepted, and the security policy stored in the security domain of the inode node corresponding to the application is loaded into the process space.

[0116] Specifically, the `bprm_set_creds` hook function is implemented in the LSM security module to intercept application process startup system calls, such as the `execv()` system call. The `bprm_set_creds` hook function finds the application's inode node based on the parameters of the process startup system call, extracts the security policy from the inode node, and stores the security policy in the process's process space.

[0117] Specifically, the bprm_set_creds hook function takes the following form:

[0118] Static int int syscall_bprm_set_creds(struct linux_binprm*bprm);

[0119] It should be noted that when an application starts, the kernel parses and loads the application's binary file, mapping program-related information into various structures, including the linux_binprm structure. The linux_binpim structure stores information such as the executable program's path, parameters, and environment variables.

[0120] The inode pointer corresponding to the application can be obtained through the kernel interface file_inode(bprm->file). The i_security field of the inode pointer stores the security policy data.

[0121] The `task` structure in the kernel contains all the information about a process, and the application's security policy is stored in the `task` structure. Specifically, the security policy is stored in the `seccomp` field of the process's `task` structure.

[0122] Specifically, the task structure is as follows:

[0123] struct task_struct{#ifdef CONFIG_THREAD_INFO_IN_TASK

[0124] / **For reasons of header soup(see current_thread_info()),this*must be the first element of task_struct.* /

[0125] struct thread_info thread_info;#endif

[0126] / *-1unrunnable,0runnable,>0stopped:* /

[0127] volatile long state; ......

[0129] struct seccomp seccomp; ......

[0131] }

[0132] The native system kernel does not support interfaces for loading security policies into processes from kernel space. Existing Seccomp technology only provides user-space interfaces and does not provide interfaces to other kernel modules. That is, the existing seccomp module only has the following interface, which can only be used by the user layer and does not support use within the kernel. The second parameter of this interface restricts the value to be passed only from user space:

[0133] static inline long seccomp_set_mode_filter(unsigned int flags,constchar__user*filter);

[0134] This invention extends the existing seccomp module by adding a set of interfaces for the security module to call. Through this interface, policies can be added from the security module to the application process space of the seccomp module.

[0135] Specifically, add the following interface to the seccomp module:

[0136] long seccomp_set_mode_internal_filter(unsigned int flags,struct sock_fprog_kern*filter);

[0137] The parameter `filter` is the security policy passed to the system.

[0138] The seccomp_set_mode_internal_filter function stores the security policy filter in the task structure.

[0139] The LSM security module intercepts the process startup system call, finds the inode node of the process application based on the parameters, extracts the security policy from the inode node, and then calls seccomp_set_mode_internal_filter to save the security policy into the process's task structure.

[0140] The seccomp module is implemented based on seccomp technology and verifies every system call made by a process. When a process makes a system call and enters kernel mode, the seccomp module retrieves the BPF security policy instructions stored in the seccomp field from the current process's task structure. The kernel BPF virtual machine executes the instructions in sequence. When an instruction prohibits the execution of the system call, the process is terminated via the SIGKILL signal, thereby achieving filtering and verification of kernel interfaces, i.e., system calls.

[0141] By storing the corresponding security policy in the seccomp field of the process task structure when the application starts, the efficiency of system call security verification is improved by directly using seccomp for system call filtering.

[0142] One specific embodiment of the present invention discloses a system call legality verification system for an operating system, such as... Figure 2 As shown, it includes the following modules:

[0143] The LSM security module is a security module implemented in kernel space based on the LSM framework, with inode nodes as the arbitration object.

[0144] The security policy configuration module is used to configure corresponding security policies for different applications in user space using seccomp-bpf.

[0145] The security policy injection module is used to inject security policies into the security domain of the inode node corresponding to the application in the LSM security module.

[0146] The system call verification module is used to intercept the process startup system calls of the application, load the security policy stored in the security domain of the inode node corresponding to the application into the process space, and verify the process's system calls according to the security policy.

[0147] Based on further improvements to the above technical solution, the LSM security module implements the inode_alloc_security and inode_init_security hook functions;

[0148] The inode_alloc_security hook function is used to request and allocate inode security domains for the created inode nodes when the operating system starts and creates inode nodes for newly created files.

[0149] The inode_init_security hook function is used to initialize the inode security domain.

[0150] Furthermore, the security policy injection module injects the security policy into the kernel space through the system call setxattr(const char*path,const char*name,const void*value,size_t size,int flags); where the parameter path represents the path of the application executable file, the parameter name represents the identifier of the LSM security module, the parameter value represents the security policy, the parameter size represents the size of the security policy, and flags is the default value;

[0151] The LSM security module also implements the inode_setxattr hook function, which is used to intercept the setxattr system call, find the inode node corresponding to the application in the LSM security module according to the path and name parameters of the setxattr system call, and store the security policy in the security domain of the inode node.

[0152] Furthermore, the LSM security module also implements the bprm_set_creds hook function, which is used to intercept the process startup system call of the application, find the inode node of the application according to the parameters of the process startup system call, extract the security policy from the inode node, and store the security policy in the process space of the process.

[0153] Furthermore, the LSM security module stores the security policy in the seccomp field of the process's task structure.

[0154] The above-described method and system embodiments are based on the same principles, and their related aspects can be referenced from each other to achieve the same technical effects. For specific implementation processes, please refer to the foregoing embodiments, which will not be repeated here.

[0155] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0156] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for validating the legality of system calls in an operating system, characterized in that, Includes the following steps: An LSM security module is implemented in kernel space based on the LSM framework, using inode nodes as the arbitration object. seccomp-bpf is used to configure corresponding security policies for different applications in user space; Inject the security policy into the security domain of the inode node corresponding to the application in the LSM security module; Intercept the application's process startup system call, load the security policy stored in the security domain of the application's corresponding inode node into the process space, and verify the process's system call according to the security policy; Injecting security policies into the security domain of the inode node corresponding to the application in the LSM security module, including: The security policy is injected into the kernel space through the system call setxattr(const char *path, const char *name, const void *value, size_t size, int flags). The parameter path represents the path of the application executable file, the parameter name represents the identifier of the LSM security module, the parameter value represents the security policy, the parameter size represents the size of the security policy, and the flags is the default value. The LSM security module also implements the inode_setxattr hook function, which is used to intercept the setxattr system call, find the inode node corresponding to the application in the LSM security module according to the path and name parameters of the setxattr system call, and store the security policy in the security domain of the inode node.

2. The system call legality verification method for an operating system according to claim 1, characterized in that, The LSM security module implements the inode_alloc_security and inode_init_security hook functions; The inode_alloc_security hook function is used to request and allocate inode security domains for the created inode nodes when the operating system starts and creates inode nodes for newly created files. The inode_init_security hook function is used to initialize the inode security domain.

3. The system call legality verification method for an operating system according to claim 1, characterized in that, The LSM security module also implements the bprm_set_creds hook function, which is used to intercept the process startup system call of the application, find the inode node of the application according to the parameters of the process startup system call, extract the security policy from the inode node, and store the security policy in the process space of the process.

4. The system call legality verification method for an operating system according to claim 3, characterized in that, The security policy is stored in the seccomp field of the task structure of the process.

5. A system call validity verification system for an operating system, characterized in that, Includes the following modules: The LSM security module is a security module implemented in kernel space based on the LSM framework, with inode nodes as the arbitration object. The security policy configuration module is used to configure corresponding security policies for different applications in user space using seccomp-bpf. The security policy injection module is used to inject security policies into the security domain of the inode node corresponding to the application in the LSM security module. The system call verification module is used to intercept the process startup system calls of the application, load the security policy stored in the security domain of the inode node corresponding to the application into the process space, and verify the process's system calls according to the security policy. The security policy injection module injects security policies into the kernel space through the system call setxattr(const char *path, const char *name, const void *value, size_t size, int flags); where the parameter path represents the path of the application executable file, the parameter name represents the identifier of the LSM security module, the parameter value represents the security policy, the parameter size represents the size of the security policy, and the flags is the default value. The LSM security module also implements the inode_setxattr hook function, which is used to intercept the setxattr system call, find the inode node corresponding to the application in the LSM security module according to the path and name parameters of the setxattr system call, and store the security policy in the security domain of the inode node.

6. The system call legality verification system for an operating system according to claim 5, characterized in that, The LSM security module implements the inode_alloc_security and inode_init_security hook functions; The inode_alloc_security hook function is used to request and allocate inode security domains for the created inode nodes when the operating system starts and creates inode nodes for newly created files. The inode_init_security hook function is used to initialize the inode security domain.

7. The system call legality verification system for an operating system according to claim 5, characterized in that, The LSM security module also implements the bprm_set_creds hook function, which is used to intercept the process startup system call of the application, find the inode node of the application according to the parameters of the process startup system call, extract the security policy from the inode node, and store the security policy in the process space of the process.

8. The system call legality verification system for an operating system according to claim 7, characterized in that, The LSM security module stores the security policy in the seccomp field of the process's task structure.

Images