CN117908991A - System access method, device, equipment and medium based on security policy loading - Google Patents

Abstract

The application provides a system access method, device, equipment and medium based on security policy loading. The method is applied to the technical field of computers and comprises the following steps: responding to a security policy loading instruction, and displaying a plurality of first scene identifications; responding to the selection operation of the second scene identifier in the plurality of first scene identifiers, and displaying at least one first security policy under the second scene identifier; determining a second security policy from the at least one first security policy and determining an LSM hook function associated with the second security policy; starting the Linux system, loading the associated LSM hook function and eBPF programs corresponding to the second security policy, and running eBPF programs corresponding to the second security policy based on the associated LSM hook function to realize access to the Linux system. The method of the application not only can realize the rapid and flexible loading and unloading of the security policy, but also ensures the security and stability of the system.

Description

System access method, device, equipment and medium based on security policy loading

Technical Field

The present application relates to the field of computer technology, and in particular to a system access method, device, equipment and medium based on security policy loading.

Background technique

With the continuous improvement of Internet technology and information technology, system security is becoming more and more important. Generally, the system security can be checked by loading security policies.

Currently, when a system loads a security policy, one method is a static security policy loading method, and the other is a dynamic loading method based on a kernel module.

Among them, the static security policy loading method mainly loads all security policies into the system kernel when the system starts, which will occupy a large amount of system resources and affect the performance of the system. The dynamic loading method based on the kernel module usually requires restarting the system to load the security policy module. In the case of a conflict between the security policy module and other modules in the system, it is necessary to first uninstall other modules in the system and then load the security policy module. This not only affects the efficiency of the system in loading security policies, but also puts the system at risk of kernel crash or malicious tampering.

Summary of the invention

The present application provides a system access method, device, equipment and medium based on security policy loading, which is used to solve the technical problems in the prior art that the security policy loading speed is slow, the flexibility is poor, and the security is low when the system performs a security check.

In a first aspect, the present application provides a system access method based on security policy loading, which is applied to a Linux system, including:

In response to the security policy loading instruction, a plurality of first scenario identifiers are displayed; wherein the first scenario identifier represents a preset application scenario corresponding to the Linux system when performing system access;

In response to a selection operation of a second scenario identifier among the multiple first scenario identifiers, at least one first security policy under the second scenario identifier is displayed; wherein the second scenario identifier represents an application scenario currently corresponding to the Linux system; and the first security policy represents a security check that can be performed under the application scenario represented by the second scenario identifier;

Determine a second security policy from the at least one first security policy, and determine an LSM hook function associated with the second security policy; wherein the LSM hook function represents a pre-set security checkpoint;

Start the Linux system, and load the associated LSM hook function and the eBPF program corresponding to the second security policy, so as to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system.

In one example, the second scenario identifier represents a preset scenario identifier; and the determining of the LSM hook function associated with the second security policy includes:

After determining the second security policy from the at least one first security policy, determining a relationship mapping table from a database corresponding to the Linux system; wherein the relationship mapping table stores an association relationship between a preset application scenario and a preset LSM hook function under the application scenario;

Based on the association relationship included in the relationship mapping table, determine at least one preset LSM hook function that matches the application scenario represented by the second scenario identifier;

From the at least one preset LSM hook function, determine the LSM hook function associated with the second security policy.

In one example, the pre-set scenario identifier represents at least the following application scenarios: a cloud computing scenario or a containerization scenario, an Internet of Things scenario or an edge computing scenario, a network security scenario or a firewall scenario.

In one example, the second scenario identifier represents a custom scenario identifier; and the determining of the LSM hook function associated with the second security policy includes:

After determining the second security policy from the at least one first security policy, displaying a bitmap selection structure; wherein the bitmap selection structure includes at least one preset LSM hook function;

Based on a selection operation of at least one preset LSM hook function in the bitmap selection structure, an LSM hook function associated with the second security policy is determined.

In one example, loading the associated LSM hook function and the eBPF program corresponding to the second security policy includes:

Based on the security policy loader, the associated LSM hook function is loaded into the Linux system, and the eBPF program corresponding to the second security policy is compiled into the corresponding LSM hook function, thereby completing the loading of the associated LSM hook function and the eBPF program corresponding to the second security policy.

In one example, the Linux system includes a security policy management interface; the method further includes:

In response to a trigger operation on the security policy management interface, a security policy management interface is displayed to perform management operations on each security policy in the Linux system in the security policy management interface; wherein the management operations include: adding operations, modifying operations, and deleting operations.

In one example, the Linux system includes a security policy viewing interface; the method further includes:

In response to a trigger operation on the security policy viewing interface, a security policy viewing interface is displayed, so that a viewing operation on each security policy in the Linux system is performed in the security policy viewing interface; wherein the viewing operation includes: a query operation and a statistical operation.

In a second aspect, the present application provides a system access device based on security policy loading, comprising:

A first display unit, configured to display a plurality of first scenario identifiers in response to a security policy loading instruction; wherein the first scenario identifiers represent pre-set application scenarios corresponding to the Linux system when performing system access;

A second display unit is used to display at least one first security policy under a second scene identifier in response to a selection operation of the second scene identifier among the multiple first scene identifiers; wherein the second scene identifier represents an application scenario currently corresponding to the Linux system; and the first security policy represents a security check that can be performed under the application scenario represented by the second scene identifier;

A determination unit, configured to determine a second security policy from the at least one first security policy, and determine an LSM hook function associated with the second security policy; wherein the LSM hook function represents a pre-set security checkpoint;

An access unit is used to start the Linux system and load the associated LSM hook function and the eBPF program corresponding to the second security policy, so as to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system.

In one example, when the second scene identifier represents a preset scene identifier, the determining unit is configured to:

After determining the second security policy from the at least one first security policy, determining a relationship mapping table from a database corresponding to the Linux system; wherein the relationship mapping table stores an association relationship between a preset application scenario and a preset LSM hook function under the application scenario;

Based on the association relationship included in the relationship mapping table, determine at least one preset LSM hook function that matches the application scenario represented by the second scenario identifier;

From the at least one preset LSM hook function, determine the LSM hook function associated with the second security policy.

In one example, the pre-set scenario identifier represents at least the following application scenarios: a cloud computing scenario or a containerization scenario, an Internet of Things scenario or an edge computing scenario, a network security scenario or a firewall scenario.

In one example, when the second scene identifier represents a customized scene identifier, the determining unit is configured to:

After determining the second security policy from the at least one first security policy, displaying a bitmap selection structure; wherein the bitmap selection structure includes at least one preset LSM hook function;

Based on a selection operation of at least one preset LSM hook function in the bitmap selection structure, an LSM hook function associated with the second security policy is determined.

In one example, the access unit is used to:

Based on the security policy loader, the associated LSM hook function is loaded into the Linux system, and the eBPF program corresponding to the second security policy is compiled into the corresponding LSM hook function, thereby completing the loading of the associated LSM hook function and the eBPF program corresponding to the second security policy.

In one example, the device further includes a management module, configured to:

In the case where the Linux system includes a security policy management interface, in response to a triggering operation on the security policy management interface, a security policy management interface is displayed so that management operations on each security policy in the Linux system are performed in the security policy management interface; wherein the management operations include: adding operations, modifying operations, and deleting operations.

In one example, the device further includes a viewing module, configured to:

In the case where the Linux system includes a security policy viewing interface, in response to a triggering operation on the security policy viewing interface, a security policy viewing interface is displayed so that a viewing operation on each security policy in the Linux system is performed in the security policy viewing interface; wherein the viewing operation includes: a query operation and a statistical operation.

In a third aspect, the present application provides a computer device, comprising: a processor, and a memory communicatively connected to the processor;

The memory stores computer-executable instructions;

The processor executes the computer-executable instructions stored in the memory to implement the method described in the first aspect.

In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method described in the first aspect.

In a fifth aspect, the present application provides a computer program product, comprising: computer execution instructions, the computer execution instructions are stored in a readable storage medium, at least one processor of a computer device can read the computer execution instructions from the readable storage medium, and the at least one processor executes the computer execution instructions, so that the computer device executes the method described in the first aspect.

The system access method, device, equipment and medium based on security policy loading provided by the present application can display multiple first scene identifiers in response to the security policy loading instruction. At this time, it can display at least one first security policy under the second scene identifier in response to the selection operation of the second scene identifier among the multiple first scene identifiers. Then, the second security policy can be determined from at least one first security policy, and the LSM hook function associated with the second security policy can be determined. At this time, after starting the Linux system, the associated LSM hook function and the eBPF program corresponding to the second security policy can be loaded to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system. This implementation method can combine eBPF and LSM to realize the need to dynamically load security policies and load LSM hook functions on demand, which can save the performance of the Linux system. At the same time, through eBPF technology, the security and reliability of loading security policies can also be improved to avoid kernel crashes or malicious tampering.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

FIG1 is a schematic diagram of a flow chart of a system access method based on security policy loading provided in an embodiment of the present application;

FIG2 is a flow chart of another system access method based on security policy loading provided in an embodiment of the present application;

FIG3 is a flowchart of an implementation of a system access method based on security policy loading provided in an embodiment of the present application;

FIG4 is a schematic diagram of the structure of a system access device based on security policy loading provided in an embodiment of the present application;

5 is a schematic diagram of the structure of another system access device based on security policy loading provided in an embodiment of the present application;

FIG6 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.

The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

The term "and/or" herein only describes an association relationship, indicating that three relationships may exist. For example, A and/or B may represent the following three situations: A exists alone, A and B exist at the same time, and B exists alone. In addition, the term "at least one" herein represents any combination of at least two of any one or more of a plurality of. For example, at least one of A, B, and C may represent any one or more elements selected from the set consisting of A, B, and C.

In the prior art, when a system loads a security policy, one method is a static security policy loading method, and the other is a dynamic loading method based on a kernel module.

Among them, the static security policy loading method mainly loads all security policies into the system kernel when the system starts. This security policy loading method cannot meet the needs of dynamic security policies, and will occupy a large amount of system resources, affecting the performance of the system.

Based on the dynamic loading method of kernel modules, a module is written in the kernel space to implement the required security policy logic. At this time, the kernel module can be loaded or unloaded on demand. First, when loading the kernel module, this method usually requires restarting the system to load the kernel module (that is, the security policy module). Moreover, when the security policy module conflicts with other modules of the kernel, the conflicting module in the kernel needs to be unloaded first, and then the security policy module is loaded. At this time, not only can the rapid loading and unloading of the security policy not be realized, which affects the loading efficiency of the kernel module, but also in the process of restarting the system or loading the kernel module, the system is at risk of kernel crash or malicious tampering, which affects the stability and security of the system. Second, when the system version changes, the security policy module needs to be recompiled to adapt to different versions of the system, which further affects the efficiency of the system loading the kernel module. Third, the method of loading security policies through kernel modules relies on the interfaces and functions provided by the kernel space, resulting in the kernel module being unable to access resources in the kernel space that do not have exposed interfaces, thereby making security checks have certain limitations.

At the same time, the above two methods of loading security policies are relatively simple and cannot meet the security policy configuration requirements in different application scenarios.

The system access method based on security policy loading provided in this application aims to combine eBPF (extended Berkeley Packet Filter) and LSM (Linux Security Modules) to realize dynamic loading of security policies to solve the above technical problems of the prior art.

The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

FIG1 is a flow chart of a system access method based on security policy loading provided by an embodiment of the present application. As shown in FIG1 , the system access method based on security policy loading includes:

S101. In response to a security policy loading instruction, display a plurality of first scenario identifiers.

The first scenario identifier represents a preset application scenario corresponding to the Linux system when the system is accessed.

In one example, the first scenario identifier may represent an application scenario corresponding to a preset Linux system, for example, the application scenario represented by the first scenario identifier may be a cloud computing scenario, or a network security scenario, etc. Alternatively, the first scenario identifier may also represent an identifier of a newly added/customized application scenario.

In one example, the first scene identifier may be displayed in the form of text and/or a picture. The display form of the first scene identifier is not limited here, and is subject to practicability.

In one example, the embodiment of the present application can pre-fabricate a security policy rule base before responding to a security policy loading instruction. At this time, the pre-fabricated security policy rule base can be used to describe various security policy configuration files under pre-defined application scenarios. At the same time, the corresponding bitmap selection structure can be generated through the association relationship between the pre-set application scenario and the LSM hook function, so as to perform a security check on the Linux system according to the bitmap selection structure corresponding to the security policy configuration file and the LSM hook function.

In one example, the security policy configuration file may include the name of the security policy, the description of the security policy (e.g., the purpose of the security policy), the name of the eBPF program file corresponding to the security policy, the operation to be performed, etc. For example, the security policy in the security policy configuration file may be used for file protection. In this case, the name of the security policy may be "file protection", the description of the security policy may be "blocking the execution of heap memory", the name of the eBPF program file corresponding to the security policy may be "file protection program", and the operation to be performed may be "blocking". The content included in the security policy configuration file is not limited here, and is subject to implementation. At the same time, it is described in Chinese here, and in actual use, a programming language may be used to describe the security policy configuration file.

S102: In response to a selection operation of a second scenario identifier among a plurality of first scenario identifiers, display at least one first security policy under the second scenario identifier.

The second scenario identifier represents the application scenario currently corresponding to the Linux system; and the first security policy represents the security check that can be performed in the application scenario represented by the second scenario identifier.

In one example, at least one first security policy can represent the security policy in the application scenario described by the prefabricated security policy rule base and represented by the second scenario identifier, or at least one first security policy can also represent all security policies within the Linux system, or at least one first security policy can also represent a newly customized security policy, etc.

S103. Determine a second security policy from at least one first security policy, and determine an LSM hook function associated with the second security policy.

Among them, the LSM hook function represents the pre-set security checkpoint.

The second security policy may be understood as a security check that needs to be performed when accessing the system. In this case, the second security policy may be at least a part of the at least one security policy.

S104, start the Linux system, and load the associated LSM hook function and the eBPF program corresponding to the second security policy, so as to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system.

It can be seen from the above description that the embodiment of the present application can display multiple first scene identifiers in response to the security policy loading instruction. At this time, in response to the selection operation of the second scene identifier among the multiple first scene identifiers, at least one first security policy under the second scene identifier can be displayed. Then, the second security policy can be determined from the at least one first security policy, and the LSM hook function associated with the second security policy can be determined. At this time, after starting the Linux system, the associated LSM hook function and the eBPF program corresponding to the second security policy can be loaded to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system. This implementation method can combine eBPF and LSM to realize the need to dynamically load security policies and load LSM hook functions on demand, which can save the performance of the Linux system. At the same time, through eBPF technology, the security and reliability of loading security policies can also be improved to avoid kernel crashes or malicious tampering.

FIG2 is a flow chart of another system access method based on security policy loading provided in an embodiment of the present application. As shown in FIG2 , the system access method based on security policy loading includes:

S201. In response to a security policy loading instruction, display a plurality of first scenario identifiers.

The first scenario identifier represents a preset application scenario corresponding to the Linux system when the system is accessed.

In an example, this step can refer to the content described in S101 above, and will not be described in detail here.

S202: In response to a selection operation of a second scenario identifier among a plurality of first scenario identifiers, display at least one first security policy under the second scenario identifier.

The second scenario identifier represents the application scenario currently corresponding to the Linux system; and the first security policy represents the security check that can be performed in the application scenario represented by the second scenario identifier.

In an example, this step can refer to the content described in S102 above, and will not be described in detail here.

S203. Determine a second security policy from at least one first security policy, and determine an LSM hook function associated with the second security policy.

Among them, the LSM hook function represents the pre-set security checkpoint.

In one example, it can be seen from the above description that the first scenario identifier can represent an application scenario corresponding to a preset Linux system, or can represent an identifier of a newly added/customized application scenario.

The pre-set scenario identifier represents at least the following application scenarios: cloud computing scenario or containerization scenario, Internet of Things scenario or edge computing scenario, network security scenario or firewall scenario. The pre-set application scenario is not specifically limited here, and it is subject to what can be realized.

In one example, after customizing an application scenario, the customized application scenario can be added to the pre-set application scenario to gradually expand the pre-set application scenario, thereby broadening the application scenario of security policy loading and improving the robustness of the system access method based on security policy loading.

At this time, in the case where the second scene identifier represents a preset scene identifier, the LSM hook function associated with the second security policy can be determined according to the following process.

First, after determining the second security policy from at least one first security policy, a relationship mapping table is determined from a database corresponding to the Linux system, wherein the relationship mapping table stores the association relationship between the preset application scenario and the preset LSM hook function in the application scenario.

Next, based on the association relationship included in the relationship mapping table, at least one preset LSM hook function matching the application scenario represented by the second scenario identifier is determined.

Then, from at least one preset LSM hook function, determine the LSM hook function associated with the second security policy.

This implementation can store in a database a relationship mapping table containing the association relationship between a preset application scenario and a preset LSM hook function under the application scenario. This not only speeds up the process of determining the LSM hook function associated with the second security policy and improves efficiency, but also reduces the professional requirements for staff who access the system based on security policy loading.

In one example, when the second scenario identifier represents a customized scenario identifier, the LSM hook function associated with the second security policy may be determined according to the process described below.

First, after determining the second security policy from at least one first security policy, a bitmap selection structure is displayed. The bitmap selection structure includes at least one preset LSM hook function. At this time, the at least one preset LSM hook function included in the bitmap selection structure can be all preset LSM hook functions, so that relevant personnel can select from all preset LSM hook functions as needed.

Then, based on a selection operation of at least one preset LSM hook function in the bitmap selection structure, an LSM hook function associated with the second security policy is determined.

In one example, a newly added identifier may be displayed in a bitmap selection structure. At this time, if all preset LSM hook functions of the Linux system do not meet the requirements, a preset LSM hook function may be added in response to a trigger operation on the newly added identifier.

In the above implementation, the bitmap selection structure can be used to intuitively and clearly display the preset LSM hook function that can be selected, so that the LSM hook function associated with the second security policy can be conveniently and quickly determined through the selection operation of the preset LSM hook function.

S204. Start the Linux system.

S205. Based on the security policy loader, the associated LSM hook function is loaded into the Linux system, and the eBPF program corresponding to the second security policy is compiled into the corresponding LSM hook function, thereby completing the loading of the associated LSM hook function and the eBPF program corresponding to the second security policy.

Among them, the eBPF program corresponding to the second security policy is used to implement the logic defined in the second security policy. At this time, the eBPF program corresponding to the second security policy is a program written in advance when the security policy rule base is prefabricated. Here, the eBPF program corresponding to the security policy can be written in C language.

In one example, when compiling the eBPF program corresponding to the second security policy into the corresponding LSM hook function, the eBPF program corresponding to the second security policy can be first compiled into an ELF format (Executable and Linkable Format) file through a compilation tool (for example, tools such as clang or bpftool), and the ELF format file is connected to the associated LSM hook function so that the LSM hook function can call the eBPF program corresponding to the second security policy.

S206. Based on the associated LSM hook function, run the eBPF program corresponding to the second security policy to achieve access to the Linux system.

In one example, Figure 3 is an implementation flow chart of a system access method based on security policy loading provided in an embodiment of the present application. As shown in Figure 3, after responding to the security policy loading instruction, an application scenario can be selected (i.e., a second scenario identifier is determined) by displaying multiple first scenario identifiers. For example, a pre-set application scenario can be selected, or a custom application scenario can be selected.

Afterwards, the security policy file can be selected and determined (i.e., the second security policy is determined) according to the prefabricated security policy rule base and at least one security policy corresponding to the selected application scenario. At the same time, the LSM hook function associated with the security policy configuration file is determined through the bitmap selection structure.

After that, you can start the Linux system, load the LSM hook function associated with the security policy configuration file, and compile the eBPF program corresponding to the security policy configuration file to inject the security policy configuration file and the associated LSM hook function into the kernel space. Based on the associated LSM hook function, you can run the eBPF program corresponding to the security policy configuration file to access the Linux system.

In one example, a Linux system may include a security policy management interface. In this case, in response to a trigger operation on the security policy management interface, the security policy management interface may be displayed so that management operations on various security policies in the Linux system may be performed in the security policy management interface. The management operations include: adding operations, modifying operations, and deleting operations.

This implementation method can manage security policies through the security policy management interface and update security policies in a timely manner according to the actual needs of system access. For example, unnecessary security policies can be deleted in a timely manner to save resources, new security policies can be added in a timely manner to meet new needs of system access, and existing security policies can be modified in real time to make system access more secure and effective, thereby realizing dynamic management of security policies.

In one example, the Linux system may include a security policy viewing interface. In this case, in response to a trigger operation on the security policy viewing interface, a security policy viewing interface may be displayed, so that a viewing operation on each security policy in the Linux system may be performed in the security policy viewing interface. The viewing operation includes: a query operation and a statistical operation.

In one example, the query operation can be used to query the specific content of the security policy; the statistical operation can be used to count part or all of the security policies. In this implementation, the existing security policy can be queried in real time through the security policy viewing interface, or the existing security policy can be counted, so that the adjustment method of the security policy can be determined through the statistical information/viewing information of the existing security policy, and the security policy can be managed/adjusted in time.

FIG4 is a schematic diagram of the structure of a system access device based on security policy loading provided in an embodiment of the present application. As shown in FIG4 , the system access device 400 based on security policy loading includes:

The first display unit 401 is used to display a plurality of first scenario identifiers in response to a security policy loading instruction; wherein the first scenario identifier represents a pre-set application scenario corresponding to the Linux system when performing system access.

The second display unit 402 is used to display at least one first security policy under the second scene identifier in response to a selection operation of the second scene identifier among multiple first scene identifiers; wherein the second scene identifier represents the application scenario currently corresponding to the Linux system; and the first security policy represents the security check that can be performed in the application scenario represented by the second scene identifier.

The determination unit 403 is used to determine a second security policy from at least one first security policy, and determine an LSM hook function associated with the second security policy; wherein the LSM hook function represents a pre-set security checkpoint.

The access unit 404 is used to start the Linux system and load the associated LSM hook function and the eBPF program corresponding to the second security policy, so as to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system.

FIG5 is a schematic diagram of the structure of another system access device based on security policy loading provided in an embodiment of the present application. As shown in FIG5 , the system access device 500 based on security policy loading includes:

The first display unit 501 is used to display a plurality of first scenario identifiers in response to a security policy loading instruction; wherein the first scenario identifier represents a pre-set application scenario corresponding to the Linux system when performing system access.

The second display unit 502 is used to display at least one first security policy under the second scene identifier in response to a selection operation of the second scene identifier among multiple first scene identifiers; wherein the second scene identifier represents the application scenario currently corresponding to the Linux system; and the first security policy represents the security check that can be performed in the application scenario represented by the second scene identifier.

The determination unit 503 is used to determine a second security policy from at least one first security policy, and determine an LSM hook function associated with the second security policy; wherein the LSM hook function represents a pre-set security checkpoint.

The access unit 504 is used to start the Linux system and load the associated LSM hook function and the eBPF program corresponding to the second security policy, so as to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system.

In one example, when the second scene identifier represents a preset scene identifier, the determining unit 503 is configured to:

After determining the second security policy from at least one first security policy, determining a relationship mapping table from a database corresponding to the Linux system; wherein the relationship mapping table stores an association relationship between a preset application scenario and a preset LSM hook function under the application scenario;

Based on the association relationship included in the relationship mapping table, determine at least one preset LSM hook function that matches the application scenario represented by the second scenario identifier;

From at least one preset LSM hook function, determine an LSM hook function associated with the second security policy.

In one example, the pre-set scenario identifier represents at least the following application scenarios: a cloud computing scenario or a containerization scenario, an Internet of Things scenario or an edge computing scenario, a network security scenario or a firewall scenario.

In one example, when the second scene identifier represents a customized scene identifier, the determining unit 503 is configured to:

After determining the second security policy from at least one first security policy, displaying a bitmap selection structure; wherein the bitmap selection structure includes at least one preset LSM hook function;

Based on a selection operation of at least one preset LSM hook function in the bitmap selection structure, an LSM hook function associated with the second security policy is determined.

In one example, the access unit 504 is configured to:

Based on the security policy loader, the associated LSM hook function is loaded into the Linux system, and the eBPF program corresponding to the second security policy is compiled into the corresponding LSM hook function, completing the loading of the associated LSM hook function and the eBPF program corresponding to the second security policy.

In one example, the device further includes a management module 505, configured to:

In the case where a security policy management interface is included in the Linux system, in response to a trigger operation on the security policy management interface, the security policy management interface is displayed so that management operations on various security policies in the Linux system can be performed in the security policy management interface; wherein the management operations include: adding operations, modifying operations, and deleting operations.

In one example, the apparatus further includes a viewing module 506, configured to:

In the case where a security policy viewing interface is included in the Linux system, in response to a trigger operation on the security policy viewing interface, a security policy viewing interface is displayed so that viewing operations on various security policies in the Linux system can be performed in the security policy viewing interface; wherein the viewing operations include: query operations and statistical operations.

FIG6 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. As shown in FIG6 , the computer device 600 includes: a memory 601 and a processor 602 .

Memory 601 is a memory used to store instructions executable by processor 602 .

The processor 602 is configured to execute the method provided in the above embodiment.

The computer device further includes a receiver 603 and a transmitter 604. The receiver 603 is used to receive instructions and data sent by an external device, and the transmitter 604 is used to send instructions and data to the external device.

The embodiment of the present application also provides a computer-readable storage medium, on which a computer-executable instruction is stored, and when the computer-executable instruction is executed by a processor, the steps of the system access method based on security policy loading in the above method embodiment are executed. The storage medium can be a volatile or non-volatile computer-readable storage medium.

An embodiment of the present application also provides a computer program product, which carries computer execution instructions. The instructions included in the computer execution instructions can be used to execute the steps of the system access method based on security policy loading in the above method embodiment. For details, please refer to the above method embodiment, which will not be repeated here.

It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

It should be further noted that, although the various steps in the flow chart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flow chart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

It should be understood that the above-mentioned device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units/modules in the above-mentioned embodiments is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

In addition, unless otherwise specified, each functional unit/module in each embodiment of the present application may be integrated into one unit/module, each unit/module may exist physically separately, or two or more units/modules may be integrated together. The above-mentioned integrated unit/module may be implemented in the form of hardware or in the form of a software program module.

If the integrated unit/module is implemented in the form of hardware, the hardware may be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. If not specifically stated, the processor may be any appropriate hardware processor, such as a CPU, a GPU, an FPGA, a DSP, an ASIC, etc. If not specifically stated, the storage unit may be any appropriate magnetic storage medium or magneto-optical storage medium, such as a resistive random access memory RRAM (Resistive Random Access Memory), a dynamic random access memory DRAM (Dynamic Random Access Memory), a static random access memory SRAM (Static Random-Access Memory), an enhanced dynamic random access memory EDRAM (Enhanced Dynamic Random Access Memory), a high-bandwidth memory HBM (High-Bandwidth Memory), a hybrid memory cube HMC (Hybrid Memory Cube), etc.

If the integrated unit/module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. 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, which is stored in a memory and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of each embodiment method of the present application. The aforementioned memory includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

In the above embodiments, the description of each embodiment has its own emphasis. For the part not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims (10)

1. A system access method based on security policy loading, characterized in that it is applied to a Linux system and comprises: In response to the security policy loading instruction, a plurality of first scenario identifiers are displayed; wherein the first scenario identifier represents a preset application scenario corresponding to the Linux system when performing system access; In response to a selection operation of a second scenario identifier among the multiple first scenario identifiers, at least one first security policy under the second scenario identifier is displayed; wherein the second scenario identifier represents an application scenario currently corresponding to the Linux system; and the first security policy represents a security check that can be performed under the application scenario represented by the second scenario identifier; Determine a second security policy from the at least one first security policy, and determine an LSM hook function associated with the second security policy; wherein the LSM hook function represents a pre-set security checkpoint; Start the Linux system, and load the associated LSM hook function and the eBPF program corresponding to the second security policy, so as to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system. 2. The method according to claim 1, characterized in that the second scenario identifier represents a preset scenario identifier; and the determining of the LSM hook function associated with the second security policy comprises: After determining the second security policy from the at least one first security policy, determining a relationship mapping table from a database corresponding to the Linux system; wherein the relationship mapping table stores an association relationship between a preset application scenario and a preset LSM hook function under the application scenario; Based on the association relationship included in the relationship mapping table, determine at least one preset LSM hook function that matches the application scenario represented by the second scenario identifier; From the at least one preset LSM hook function, determine the LSM hook function associated with the second security policy. 3. The method according to claim 2 is characterized in that the pre-set scenario identifier represents at least the following application scenarios: cloud computing scenario or containerization scenario, Internet of Things scenario or edge computing scenario, network security scenario or firewall scenario. 4. The method according to claim 1, wherein the second scenario identifier represents a custom scenario identifier; and the determining of the LSM hook function associated with the second security policy comprises: After determining the second security policy from the at least one first security policy, displaying a bitmap selection structure; wherein the bitmap selection structure includes at least one preset LSM hook function; Based on a selection operation of at least one preset LSM hook function in the bitmap selection structure, an LSM hook function associated with the second security policy is determined. 5. The method according to claim 1, characterized in that the loading of the associated LSM hook function and the eBPF program corresponding to the second security policy comprises: Based on the security policy loader, the associated LSM hook function is loaded into the Linux system, and the eBPF program corresponding to the second security policy is compiled into the corresponding LSM hook function, thereby completing the loading of the associated LSM hook function and the eBPF program corresponding to the second security policy. 6. The method according to any one of claims 1 to 5, characterized in that the Linux system includes a security policy management interface; the method further comprises: In response to a trigger operation on the security policy management interface, a security policy management interface is displayed to perform management operations on each security policy in the Linux system in the security policy management interface; wherein the management operations include: adding operations, modifying operations, and deleting operations. 7. The method according to any one of claims 1 to 5, characterized in that the Linux system includes a security policy viewing interface; the method further comprises: In response to a trigger operation on the security policy viewing interface, a security policy viewing interface is displayed, so that a viewing operation on each security policy in the Linux system is performed in the security policy viewing interface; wherein the viewing operation includes: a query operation and a statistical operation. 8. A system access device based on security policy loading, characterized by comprising: A first display unit, configured to display a plurality of first scenario identifiers in response to a security policy loading instruction; wherein the first scenario identifiers represent pre-set application scenarios corresponding to the Linux system when performing system access; A second display unit is used to display at least one first security policy under a second scene identifier in response to a selection operation of the second scene identifier among the multiple first scene identifiers; wherein the second scene identifier represents an application scenario currently corresponding to the Linux system; and the first security policy represents a security check that can be performed under the application scenario represented by the second scene identifier; A determination unit, configured to determine a second security policy from the at least one first security policy, and determine an LSM hook function associated with the second security policy; wherein the LSM hook function represents a pre-set security checkpoint; An access unit is used to start the Linux system and load the associated LSM hook function and the eBPF program corresponding to the second security policy, so as to run the eBPF program corresponding to the second security policy based on the associated LSM hook function to achieve access to the Linux system. 9. A computer device, comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the system access method based on security policy loading according to any one of claims 1 to 7. 10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the system access method based on security policy loading as described in any one of claims 1 to 7.