SELinux policy construction method, device, electronic device and readable storage medium

Abstract

The present application provides a SELinux policy construction method, device, electronic device and readable storage medium, wherein the method includes: generating an initial policy according to the path of the executable file of the software to be monitored; based on the initial policy, testing the software to be monitored to obtain the security log generated during the test process; sending the security log to a server so that the server can generate an update policy based on the security log; receiving the update policy sent by the server, and using the update policy to update the current policy, wherein when the policy is updated for the first time, the current policy is the initial policy.

Description

Technical Field

[0001] The present application relates to the field of computer security, and in particular to a SELinux policy construction method, device, electronic device and readable storage medium. Background Art

[0002] SELinux (Security-Enhanced Linux) is an implementation of mandatory access control (MAC). SELinux controls subject behavior through policy rules. Currently, the early development of policy rules mainly relies on SELinux R&D personnel, resulting in difficulty in developing and maintaining SELinux policy rules. Summary of the Invention

[0003] The purpose of this application is to provide a SELinux policy construction method, device, electronic device and readable storage medium to improve the problem of difficulty in developing and maintaining SELinux policy rules.

[0004] In a first aspect, the present invention provides a SELinux policy construction method, comprising: generating an initial policy based on the path of the executable file of the software to be monitored; testing the software to be monitored based on the initial policy to obtain the security log generated during the test; sending the security log to a server so that the server can generate an update policy based on the security log; receiving the update policy sent by the server, and using the update policy to update the current policy, wherein, when the policy is updated for the first time, the current policy is the initial policy.

[0005] In an optional embodiment, the generating of the initial strategy based on the path of the executable file of the software to be monitored includes: generating a subject initial strategy based on the path of the executable file of the software to be monitored; generating an object initial strategy based on the path of the target file to be monitored by the executable file of the software to be monitored.

[0006] In the above implementation, the initial strategy includes the subject initial strategy and the object initial strategy, so that the subject and the object can be better marked separately, and the behavior of the subject and the object of the subject's behavior can be better located through the subject initial strategy and the object initial strategy.

[0007] In an optional embodiment, the subject initial policy includes a subject security label; generating the subject initial policy based on the path of the executable file of the software to be monitored includes: determining the subject process name based on the path of the executable file of the software to be monitored; and determining the subject security label in the subject initial policy based on the subject process name.

[0008] In the above implementation, the process name can be directly presented in the subject security label, which can better locate the subject, so that the subject operation can be recorded in the security log.

[0009] In an optional embodiment, the object initialization policy includes an object security label; the object initialization policy is generated based on the path of the target file to be monitored by the executable file of the software to be monitored, including: determining the file name and one or more levels of directories based on the path of the target file to be monitored by the executable file of the software to be monitored; and determining the object security label based on the file name and one or more levels of directories.

[0010] In the above implementation, the absolute path of the object can be inferred from the object security tag, which facilitates the location of the file that the subject acts on, and thus enables a more accurate analysis of the subject's operations.

[0011] In an optional embodiment, the object initialization policy includes an object security label; the object initialization policy is generated based on the path of the target file that needs to be monitored by the executable file of the software to be monitored, including: if the number of directories in the path of the target file that needs to be monitored by the executable file of the software to be monitored is greater than N1, determining the N1-level directory, where N1 is a positive integer greater than 1; determining the object security label based on the N-level directory and the file name of the subdirectory in the N1-level directory.

[0012] In the above embodiment, the object initial policy includes an object security label;

[0013] The object initialization policy is generated based on the path of the target file that needs to be monitored by the executable file of the software to be monitored, including: if the total number of files in the path of the target file that needs to be monitored by the executable file of the software to be monitored is greater than N2, N3 target files are determined, where N2 is a positive integer greater than 1 and N3 is a positive integer less than or equal to N2; based on the paths of the N3 target files, the object security labels corresponding to the N3 target files are determined.

[0014] In the above implementation, the number of directories or the total number of files in the path of the object's file can also be identified. When the number is too large, a large number of object security labels can be avoided. Some level directories can be appropriately extracted to generate object security labels, thereby improving the efficiency of initial policy generation.

[0015] In an optional embodiment, the subject initial policy includes a mode field and a risk flag, the mode field is used to mark the current operating mode of the subject corresponding to the subject initial policy; the risk flag is used to mark the behavior processing method of the subject corresponding to the subject initial policy; the method also includes: for any target subject initial policy, according to the actual values ​​of the mode field and the risk flag, processing the subject behavior corresponding to the target subject initial policy.

[0016] In the above implementation, different motion modes of the subject can also be set to adapt to the strategy construction at different progress, and the strategy can be improved while maintaining the safety of the equipment.

[0017] In an optional embodiment, the operating mode includes: a learning mode, a mixed mode and a forced mode, and the value of the risk flag includes a first value and a second value;

[0018] The processing of the target subject behavior corresponding to the target subject initial policy according to the mode field and the actual value of the risk flag bit includes:

[0019] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in learning mode, the illegal behavior of the target subject corresponding to the target subject's initial policy is allowed and recorded in the security log;

[0020] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in a mandatory mode, intercept the illegal behavior of the target subject corresponding to the target subject's initial policy and record it in a security log;

[0021] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in a mixed mode, and the actual value of the risk flag is the first value, intercept the illegal behavior of the target subject corresponding to the target subject's initial policy and record it in a security log;

[0022] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in mixed mode, and the actual value of the risk flag is the second value, the illegal behavior of the target subject corresponding to the target subject's initial policy is released and the security log is recorded.

[0023] In the above implementation, multiple operating modes and risk flag values ​​can be set, and the restrictions on the subject's operations can be adjusted by adjusting the fields in the target subject's initial policy to meet the needs of different scenarios.

[0024] In a second aspect, the present invention provides a SELinux policy construction method, comprising:

[0025] Receiving a security log sent by a client, wherein the security log is a security log generated by the client when testing the software to be monitored based on an initial policy;

[0026] An update policy is generated according to the security log, and the update policy is sent to the client, so that the client updates the current policy using the update policy.

[0027] In an optional embodiment, the security log carries a subject security label and an object security label;

[0028] The generating of the update policy according to the security log includes: generating the update policy according to the subject security label and the object security label, wherein the update policy includes subject information, object information and subject actions on the object.

[0029] In a third aspect, the present invention provides a SELinux policy construction device, comprising:

[0030] A first generating module, configured to generate an initial strategy according to the path of the executable file of the software to be monitored;

[0031] A testing module, configured to test the software to be monitored based on the initial policy to obtain security logs generated during the testing process;

[0032] A first sending module, configured to send the security log to a server, so that the server generates an update strategy according to the security log;

[0033] The first receiving module is configured to receive the update policy sent by the server and use the update policy to update the current policy. When the policy is updated for the first time, the current policy is the initial policy.

[0034] In a fourth aspect, the present invention provides a SELinux policy construction device, comprising:

[0035] A second receiving module is configured to receive a security log sent by a client, wherein the security log is a security log generated by the client when testing the software to be monitored based on an initial policy;

[0036] The second generating module is configured to generate an update policy according to the security log, and send the update policy to the client, so that the client can use the update policy to update the current policy.

[0037] In a fifth aspect, the present invention provides an electronic device comprising: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method described in any one of the aforementioned embodiments.

[0038] In a sixth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which executes the steps of the method described in any one of the aforementioned embodiments when the computer program is executed by a processor.

[0039] The beneficial effects of the embodiments of the present application include: by automatically generating an initial policy, the requirements for R&D personnel during the SELinux policy construction process can be reduced, and the efficiency of initial policy generation can be improved. Furthermore, based on the security logs generated by the testing of the monitored software, an update policy can be generated to improve the SELinux policy, thereby improving the security of the operating system while reducing the difficulty of SELinux policy rule development and maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0041] Figure 1 A schematic diagram of interaction between a first terminal and a second terminal provided in an embodiment of the present application;

[0042] Figure 2 A block diagram of an electronic device provided in an embodiment of the present application;

[0043] Figure 3 Flowchart of the SELinux policy construction method provided in the embodiment of the present application;

[0044] Figure 4 An optional flowchart of step 310 of the SELinux policy construction method provided in an embodiment of the present application;

[0045] Figure 5 A schematic diagram of the functional modules of the SELinux policy construction device provided in an embodiment of the present application;

[0046] Figure 6 A flowchart of another SELinux policy construction method provided in an embodiment of the present application;

[0047] Figure 7A schematic diagram of the functional modules of another SELinux policy construction device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application.

[0049] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0050] In computer security, mandatory access control (MAC) refers to a type of access control enforced by the operating system. The goal is to restrict a subject's ability to access or perform certain operations on an object. The subject is typically a process or thread, while the object can be a file, directory, TCP (Transmission Control Protocol) / UDP (User Datagram Protocol) port, shared memory segment, I / O (Input / Output) device, and so on. Security-Enhanced Linux (SELinux) is one implementation of mandatory access control (MAC).

[0051] SELinux controls the behavior of the subject through policy rules. SELinux has two operating modes: learning mode and enforcement mode. In enforcement mode, if the process behavior violates the policy rules, the current behavior will be intercepted; in learning mode, the process behavior that violates the policy rules will not be intercepted, but will be recorded in the SELinux log. These log records can be used to assist in the development of SELinux policy rules. The current preliminary development of SELinux policy rules mainly relies on SELinux R&D personnel. The development process is complicated, and the later stage is generally completed using tools based on SELinux logs. Because of SELinux's "whitelist" implementation mechanism (intercepting all behaviors that are not authorized in the policy rules), if the policy rules are not fully developed, it may cause some normal behaviors of the device but not included in the whitelist, which may be intercepted, resulting in more abnormalities in the device.

[0052] Based on the above research, in order to solve the complex problems of SELinux policy construction and use, the present application provides a SELinux policy construction method, device, electronic device and readable storage medium. The SELinux policy construction method provided by the present application is described below through some embodiments.

[0053] To facilitate understanding of this embodiment, the operating environment of the SELinux policy construction method disclosed in the embodiment of this application is first introduced in detail.

[0054] like Figure 1 , which is a schematic diagram of the interaction between a first terminal 110 and a second terminal 120 provided in an embodiment of the present application. The second terminal 120 is connected to one or more first terminals via a network for data communication or interaction. The second terminal 120 can be a network server, a database server, etc., or a personal computer (PC), a tablet computer, a smartphone, a personal digital assistant (PDA), etc. The first terminal 110 can be a personal computer (PC), a tablet computer, a smartphone, a personal digital assistant (PDA), etc.

[0055] In this embodiment, the first terminal 110 may store the latest SELinux policy, and the first terminal may control the main behavior of the first terminal based on the SELinux policy. The first terminal may also be deployed with a client. The client may receive the SELinux policy and update the local policy.

[0056] A server may be deployed in the second terminal 120 . After the client and the server establish a link, the client may send the SELinux security log to the server.

[0057] In one example, the client deployed on the first terminal 110 may be a rsyslogd client, and the server deployed on the second terminal 120 may be a rsyslogd server. After the rsyslogd client establishes a link with the rsyslogd server, SELinux security logs can be sent to the rsyslogd server via the rsyslogd client.

[0058] Figure 1 The first terminal 110 and the second terminal 120 shown in FIG. 1 may be electronic devices having storage functions and processing functions. Figure 2As shown, the electronic device 200 may include a memory 211 and a processor 213. A person skilled in the art will understand that Figure 2 The structure shown is only for illustration and does not limit the structure of the electronic device 200. For example, the electronic device 200 may further include Figure 2 More or fewer components than shown, or with Figure 2 Different configurations shown.

[0059] The memory 211 and processor 213 are electrically connected to each other, directly or indirectly, to enable data transmission or interaction. For example, these components may be electrically connected to each other via one or more communication buses or signal lines. The processor 213 is used to execute the executable modules stored in the memory.

[0060] The memory 211 may be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. The memory 211 is used to store a program, and the processor 213 executes the program after receiving an execution instruction. The method executed by the electronic device 200 defined by the process disclosed in any embodiment of the present application can be applied to the processor 213 or implemented by the processor 213.

[0061] The processor 213 may be an integrated circuit chip with signal processing capabilities. The processor 213 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed. The general-purpose processor may be a microprocessor or any conventional processor.

[0062] The electronic device 200 in this embodiment can be used to execute each step in each method provided in the embodiments of this application. The following describes in detail the implementation process of the SELinux policy construction method through several embodiments.

[0063] See also Figure 3 , is a flowchart of the SELinux policy construction method provided by the embodiment of the present application. The steps in the method of this embodiment can be Figure 1 The first terminal shown in FIG. 1 can also execute the client running in the first terminal. Figure 3 The specific process shown is described in detail.

[0064] Step 310: Generate an initial policy based on the path of the executable file of the software to be monitored.

[0065] In this embodiment, the initial policy may include a subject initial policy of the process of the software to be monitored. The initial policy may also include an object initial policy of the object that the software to be monitored needs to operate. The object may be a file, directory, etc. that the software to be monitored needs to operate.

[0066] Optionally, a policy generation tool may be used to generate an initial policy based on the path of the executable file of the software to be monitored. Exemplarily, the path of the executable file of the software to be monitored may be the absolute path of the executable file of the software to be monitored.

[0067] Exemplarily, the policy generation tool may be get_policy_1.0. By storing the path of the executable file of the software to be monitored in a specified file and then executing the policy generation tool get_policy_1.0, the policy generation tool get_policy_1.0 may generate an initial policy according to the path of the executable file of the software to be monitored in the specified file.

[0068] In one example, the designated file may be selinux_process.conf, which may receive paths to executable files of all software that needs to be monitored. The paths configured in the designated file selinux_process.conf may be set as needed.

[0069] Step 320: Based on the initial policy, the software to be monitored is tested to obtain security logs generated during the test.

[0070] For example, the software to be monitored can be tested using test cases to generate a security log during the test process. The security log can record process information of the software to be monitored, as well as operations performed by the process.

[0071] Exemplarily, the security log may be a SELinux interception log.

[0072] Step 330: Send the security log to the server so that the server can generate an update strategy based on the security log.

[0073] Exemplarily, after receiving the security log, the server may generate an update strategy based on the security log.

[0074] In one example, you can use the audit2allow tool to generate specific policy rules based on security logs.

[0075] Step 340: Receive the update policy sent by the server, and use the update policy to update the current policy.

[0076] When the policy is updated for the first time, the current policy is the initial policy. As the policy in the client is updated, the current policy can also be continuously improved.

[0077] In this embodiment, by automatically generating an initial policy, the requirements for R&D personnel during SELinux policy construction can be reduced, and the efficiency of initial policy generation can be improved. Furthermore, based on the security logs generated by testing the monitored software, an update policy can be generated to improve the SELinux policy, thereby improving the security of the operating system while reducing the difficulty of SELinux policy rule development and maintenance.

[0078] Considering the various functions running in the software to be monitored, in addition to the role of the execution subject, it also includes the objects under the action of the execution subject. Based on this, the initial strategy can include the subject initial strategy and the object initial strategy. Figure 4 As shown, step 310 may include step 311 and step 312 .

[0079] Step 311: Generate a subject initial policy according to the path of the executable file of the software to be monitored.

[0080] Illustratively, the subject initial policy includes a subject security label.

[0081] The above-mentioned step 311 may include: determining a subject process name according to the path of the executable file of the software to be monitored; and determining a subject security label in the subject initial policy according to the subject process name.

[0082] In one example, the path of the executable file of the software to be monitored may include / usr / sbin / ntpd and / usr / local / sbin / sshd.

[0083] In the example / usr / sbin / ntpd, the main process name that can be extracted is ntpd, and a main security label can be generated based on the process name ntpd. In the example / usr / local / sbin / sshd, the main process name that can be extracted is sshd, and a main security label can be generated based on the process name sshd.

[0084] Exemplarily, a specified character can be added to the process name to obtain a subject security label. In one example, the specified character can be proc_t.

[0085] Taking the above two examples as examples, the subject security labels that can be obtained are ntpd_proc_t and sshd_proc_t respectively.

[0086] In this embodiment, the policy generation tool get_policy_1.0 can be used to automatically generate a security label for the process of the software to be monitored based on the rule of "subject security label = process name + proc_t" and generate policy rules at the same time.

[0087] In an example, the policy rule can be: type_transition source_type target_type:process process_type;

[0088] Among them, source_type represents the set of security labels of all processes in the system, target_type represents the security label of the executable file corresponding to the process; process_type represents the process security label.

[0089] The above security label configuration can ensure that the main process uses the expected security label when any parent process executes the specified executable program.

[0090] Step 312: Generate an object initialization policy based on the path of the target file to be monitored by the executable file of the software to be monitored.

[0091] In this embodiment, the object initial policy includes an object security label.

[0092] Optionally, the absolute path of the file that needs to set the object security label can be configured in the specified file, so that the policy generation tool get_policy_1.0 can be used to automatically scan the absolute path in the specified file and generate the object security label corresponding to each file.

[0093] In one embodiment, step 312 may include: determining the file name and one or more levels of directories based on the path of the target file to be monitored by the executable file of the software to be monitored; and determining the object security label based on the file name and one or more levels of the directory.

[0094] The number of levels of the target file's directory is determined according to the storage location of the target file.

[0095] Optionally, the policy generation tool get_policy_1.0 can automatically scan the absolute paths of the files involved in the software to be monitored and automatically generate the object initial policy. Optionally, the policy generation tool get_policy_1.0 can automatically scan the absolute paths of the files required to be monitored by the software to be monitored and automatically generate the object initial policy.

[0096] Exemplarily, the object security tag = file name root directory - file name sub-root directory - ... - file name, wherein the hierarchy of the file directory can be determined according to the file storage location.

[0097] For example, if the absolute path of a file to be monitored is / etc / passwd, then the object security label of that file is etc-passwd. For another example, if the absolute path of a file to be monitored is / etc / ssh / ssh_config, then the object security label of that file is etc-ssh-ssh_config.

[0098] Optionally, the absolute paths of the files to be monitored can be pre-configured in a designated file, and the policy generation tool get_policy_1.0 can automatically scan the absolute paths of the files in the designated file to automatically generate the object initial policy. The designated file is selinux_file.conf.

[0099] Optionally, when the file name under the parent directory is not written into the specified file, the file under the parent directory may use a security label based on the parent directory name by default.

[0100] In one example, a parent directory includes multiple files, namely A / B / F1 / f11, A / B / F1 / f12, and A / B / F1 / f13. However, the absolute paths of f11, f12, and f13 are not configured in the specified file. In this case, the object security labels for files f11, f12, and f13 may not be generated, and only the object security label for their parent directory A / B / F1 may be generated. The object security label of the parent directory A / B / F1 can be expressed as: AB-F1. The child files under the parent directory A / B / F1 can all use the object security label of the parent directory.

[0101] In some practical scenarios, the number of files involved in the software to be monitored may be relatively large, or the directory hierarchy of the files involved may be relatively deep. If object security labels are set for all files, this may result in a large configuration and a large number of object security labels. Based on this, step 312 may include: if the number of directories in the path of the target file to be monitored by the executable file of the software to be monitored is greater than N1, determining the N1-level directory, and determining the object security label based on the N1-level directory and the file names of the subdirectories within the N-level directory.

[0102] Wherein, N1 is a positive integer greater than 1. N1 can be set as needed, for example, the value of N1 can be 5, 6, 7, etc.

[0103] Exemplarily, if the N-level directory includes M sub-directories, then M object security labels may be generated under the N-level directory.

[0104] If the M subdirectories also include multiple directories or files, then the M subdirectories also include multiple directories or files that use the M object security labels.

[0105] In one embodiment, step 312 may include: if the total number of files in the path of the target files that need to be monitored by the executable file of the software to be monitored is greater than N2, determining N3 target files, where N2 is a positive integer greater than 1, and N3 is a positive integer less than or equal to N2; based on the paths of the N3 target files, determining the object security labels corresponding to the N3 target files.

[0106] For the remaining target files other than the aforementioned N3 target files, the object security label of their parent directory may be used.

[0107] Among them, the above-mentioned N2 can be set as needed, for example, the N2 can be 20, 50, 100, 150, etc.

[0108] For example, the selection of the N3 target files can be configured by the user based on actual access frequency or access requirements. For example, the user can configure the N3 target files in a designated file. The policy generation tool get_policy_1.0 can automatically scan the absolute path of each of the N3 target files in the designated file to automatically generate an object security label.

[0109] For example, the N3 target files may be determined based on other criteria. For example, the selection may begin from the root directory and progress through the directories until the N3 target files are selected. Alternatively, the N3 target files may be randomly selected. In practical situations, the method for selecting the N3 target files may be customized based on actual needs.

[0110] In one embodiment, step 312 may include: for any designated directory to be monitored by the software to be monitored, if the number of files in the designated directory is greater than a set number, an object security label may be set for the designated directory.

[0111] All files or subdirectories under the specified directory can use the object security label of the specified directory.

[0112] Through the above configuration, an appropriate amount of object security labels can be set for the object files to avoid a large number of object security labels. Some level directories can be appropriately extracted to generate object security labels, thereby improving the efficiency of initial policy generation.

[0113] To adapt the SELinux policy construction method to more application scenarios, for example, for some processes with well-established policy rules, the enforcement mode can be used to ensure the security of the device using the SELinux policy. For some processes that still need improvement, the learning mode can be used to continuously improve the policy rules of such processes without causing abnormal interception of such processes by the device using the SELinux policy. Therefore, multiple operation modes can be set for the SELinux policy.

[0114] Optionally, the subject initial policy includes a mode field and a risk flag, wherein the mode field is used to mark the current operation mode of the subject corresponding to the subject initial policy; and the risk flag is used to mark the behavior processing method of the subject corresponding to the subject initial policy.

[0115] The SELinux policy construction method in this embodiment may further include: for any target subject initial policy, processing the subject behavior corresponding to the target subject initial policy according to the actual values ​​of the mode field and the risk flag.

[0116] Exemplarily, the operating modes include: a learning mode, a mixed mode, and a forced mode, and the value of the risk flag includes a first value and a second value.

[0117] In one example, the mode field may be represented as: is_mixed.

[0118] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in learning mode, the illegal behavior of the target subject corresponding to the target subject's initial policy is allowed and recorded in the security log.

[0119] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in the mandatory mode, the illegal behavior of the target subject corresponding to the target subject's initial policy is intercepted and recorded in the security log.

[0120] For example, you can configure a process that has learned some policy rules to be in enforcement mode. For example, you can configure enforcement mode in a specified file. For example, in the selinux_process.conf file, configure the absolute path of the process as: / usr / sbin / ntpd-enforce. This sets the ntpd process to enforcement mode, intercepting illegal activity within the process and generating interception logs.

[0121] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in mixed mode, and the actual value of the risk flag is the first value, the illegal behavior of the target subject corresponding to the target subject's initial policy is intercepted and a security log is recorded.

[0122] If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in mixed mode, and the actual value of the risk flag is the second value, the illegal behavior of the target subject corresponding to the target subject's initial policy is released and the security log is recorded.

[0123] In one example, the first value may be 1, and the second value may be 0.

[0124] Optionally, the actual value of the above-mentioned mode field can be three values, each value corresponding to an operating mode. In one embodiment, when the actual value of the mode field is 0, it indicates that the operating mode is learning mode; when the actual value of the mode field is 1, it indicates that the operating mode is mixed mode; when the actual value of the mode field is 2, it indicates that the operating mode is forced mode.

[0125] The following table shows how to handle illegal behaviors of subjects in different modes:

[0126] is_mixed value High-risk flag Results of handling illegal behavior 0 (Learning Mode) 0 Generate SElinux security logs and allow illegal behavior 0 (Learning Mode) 1 Generate SElinux security logs and allow illegal behavior 1 (blend mode) 0 Generate SElinux security logs and allow illegal behavior 1 (blend mode) 1 Generate SElinux security logs to intercept illegal behavior 2 (Forced mode) 0 Generate SElinux security logs to intercept illegal behavior 2 (Forced mode) 1 Generate SElinux security logs to intercept illegal behavior

[0127] Optionally, the security logs generated in the hybrid mode can be divided into interception logs and learning logs. For example, the logs generated for the process with a high risk flag of 0 are determined as learning logs, and for example, the logs generated for the process with a high risk flag of 1 are determined as interception logs.

[0128] Among them, the learning log can be used to further improve the policy rules, and the specific illegal behavior of the process can also be analyzed based on the interception log.

[0129] The above process can be repeated until the policy rules for all processes of the software to be monitored are complete.

[0130] The SELinux policy construction method of this embodiment can be applied to all Linux kernel-based operating systems.

[0131] In this embodiment, if the current operating system needs to be security-hardened, processes that need to run for a long time on the device can be screened out for behavior control. Then, the absolute paths of the executable files corresponding to the processes to be monitored can be configured in the designated file selinux_process.conf. Finally, based on the interception behavior logs generated by daily testing, the audit2allow tool is used to automatically generate policy rules for these processes based on the interception behavior logs. This can reduce users' demand for SELinux policies, reduce the cost of tool learning for R&D personnel, reduce the difficulty of developing SELinux policy rules, and reduce the cost of using SELinux tools.

[0132] In some cases, if it is not possible to ensure that the policy rules for all processes have been developed, but some high-risk processes (such as sshd, nginx, mysql, etc.) need to be configured in enforcement mode to improve the security of devices using SELinux policies, the SELinux mode can be configured to mixed mode, and processes such as sshd, nginx, and mysql can be configured in enforcement mode, while other processes continue to run in learning mode. This can ensure the security of devices using SELinux policies while preventing device anomalies due to lack of policy rules. Mixed mode can take into account both security and stability, while increasing the flexibility of SELinux, allowing users to adjust the use of SELinux according to the system security level.

[0133] By setting the hybrid mode, the behavior of sshd, nginx, and mysql can be restricted at the kernel level. If a remote attacker invades the sshd, nginx, or mysql processes to access other confidential files on the device, these abnormal behaviors will be blocked by the SELinux policy. Users can also quickly locate the attacker's specific behavior through logs.

[0134] Furthermore, since security labels are set for each subject and object, the absolute path of the object acted upon by the subject can be accurately located through the security labels in the security log, and the specific information of the accessed file can be accurately located.

[0135] Based on the same application concept, the embodiments of the present application also provide a SELinux policy construction device corresponding to the SELinux policy construction method. Since the principle of solving the problem by the device in the embodiments of the present application is similar to that of the aforementioned SELinux policy construction method embodiment, the implementation of the device in this embodiment can refer to the description in the embodiment of the above method, and the repeated parts will not be repeated.

[0136] See also Figure 5 , is a functional module diagram of the SELinux policy construction device provided in an embodiment of the present application. The modules in the SELinux policy construction device in this embodiment are used to execute the various steps in the above method embodiment. The SELinux policy construction device includes: a first generation module 410, a testing module 420, a first sending module 430, and a first receiving module 440; the contents of each module are as follows:

[0137] A first generating module 410 is configured to generate an initial policy according to the path of the executable file of the software to be monitored;

[0138] A testing module 420 is configured to test the software to be monitored based on the initial policy to obtain security logs generated during the testing process;

[0139] A first sending module 430 is configured to send the security log to the server, so that the server can generate an update strategy based on the security log;

[0140] The first receiving module 440 is configured to receive the update policy sent by the server and use the update policy to update the current policy. When the policy is updated for the first time, the current policy is the initial policy.

[0141] In a possible implementation, the first generation module 410 includes a first generation unit and a second generation unit:

[0142] A first generating unit, configured to generate a subject initial policy according to a path of an executable file of the software to be monitored;

[0143] The second generating unit is configured to generate an object initialization policy according to a path of a target file to be monitored by the executable file of the software to be monitored.

[0144] In one possible implementation, the subject initial policy includes a subject security label;

[0145] The first generating unit is configured to determine a subject process name according to a path of an executable file of the software to be monitored; and determine a subject security label in the subject initial policy according to the subject process name.

[0146] In one possible implementation, the object initialization policy includes an object security label;

[0147] The second generating unit is used to determine the file name and one or more levels of directories according to the path of the target file to be monitored by the executable file of the monitored software; and determine the object security label according to the file name and one or more levels of directories.

[0148] In one possible implementation, the second generation unit is used to determine the N1-level directory if the number of directories in the path of the target file that needs to be monitored by the executable file of the software to be monitored is greater than N1, where N1 is a positive integer greater than 1; and determine the object security label based on the N1-level directory and the file name of the subdirectory in the N1-level directory.

[0149] In one possible implementation, the second generation unit is used to determine N3 target files if the total number of files in the path of the target files that need to be monitored by the executable file of the software to be monitored is greater than N2, where N2 is a positive integer greater than 1 and N3 is a positive integer less than or equal to N2; and determine the object security labels corresponding to the N3 target files based on the paths of the N3 target files.

[0150] In one possible implementation, the subject initial policy includes a mode field and a risk flag. The mode field is used to mark the current operating mode of the subject corresponding to the subject initial policy; the risk flag is used to mark the behavior processing method of the subject corresponding to the subject initial policy.

[0151] The SELinux policy construction device of this embodiment may further include: a processing module for processing, for any target subject initial policy, the subject behavior corresponding to the target subject initial policy according to the actual values ​​of the mode field and the risk flag.

[0152] In a possible implementation, the operating mode includes: a learning mode, a mixed mode, and a forced mode, and the value of the risk flag includes a first value and a second value;

[0153] A processing module is used to, if the actual value of the pattern field in the initial policy of the target subject indicates that the target subject is in a learning mode, release the illegal behavior of the target subject corresponding to the initial policy of the target subject and record a security log; if the actual value of the pattern field in the initial policy of the target subject indicates that the target subject is in a mandatory mode, intercept the illegal behavior of the target subject corresponding to the initial policy of the target subject and record a security log; if the actual value of the pattern field in the initial policy of the target subject indicates that the target subject is in a mixed mode, and the actual value of the risk flag is a first value, intercept the illegal behavior of the target subject corresponding to the initial policy of the target subject and record a security log; if the actual value of the pattern field in the initial policy of the target subject indicates that the target subject is in a mixed mode, and the actual value of the risk flag is a second value, release the illegal behavior of the target subject corresponding to the initial policy of the target subject and record a security log.

[0154] See also Figure 6 , is a flowchart of the SELinux policy construction method provided by the embodiment of the present application. The steps in the method of this embodiment can be Figure 1 The second terminal shown in FIG. 1 can also be executed by the server running in the second terminal. Figure 6 The specific process shown is described in detail.

[0155] Step 510: Receive the security log sent by the client.

[0156] The security log is a security log generated by the client when testing the software to be monitored based on the initial policy.

[0157] Optionally, the server of the second terminal may receive the security log transmitted by the client of the first terminal.

[0158] Step 520: Generate an update policy based on the security log, and send the update policy to the client, so that the client can use the update policy to update the current policy.

[0159] Optionally, subject information, object information, and information about operations performed by the subject on the object may be extracted from the security log.

[0160] An update strategy may be generated based on the subject information, the object information, and the operation information performed by the subject on the object.

[0161] Exemplarily, the security log carries a subject security label and an object security label.

[0162] Step 520 may include: generating an update policy based on the subject security label and the object security label, wherein the update policy includes subject information, object information, and actions of the subject on the object.

[0163] Optionally, a designated policy generation tool may be used to analyze the security log to obtain an update policy. For example, the designated policy generation tool may be an audit2allow tool.

[0164] Optionally, the absolute path of the object can be determined based on the object security label, and the subject process can be determined based on the subject security label.

[0165] In one example, the security log might look like this:

[0166] 2022-05-05T11:23:27+08:00localhost kernel:audit:type=1400audit(1651721007.306:1698887):avc:denied{open read}for pid=27463comm="sshd" name="ssh_config" dev="rootfs"ino=2019scontext=system_u:system_r:sshd_proc_t:s0 tcontext=system_u:object_r:etc-ssh-ssh_config:s0 tclass=file permissive=1

[0167] 2022-05-05T11:23:20+08:00localhost kernel:audit:type=1400audit(1651721001.009:1698868):avc:denied{open}for pid=14884comm="sshd" name="passwd" dev="rootfs"ino=2019scontext=system_u:system_r:service_sshd:s0tcontext=system_u:object_r:etc-passwd:s0 tclass=file permissive=1

[0168] By analyzing the above security logs, we can determine that the subject security label is: sshd_proc_t, and the object security labels are: etc-ssh-ssh_confi and etc-passwd.

[0169] Based on the two logs above, the audit2allow tool is used to obtain the following two update policy rules:

[0170] allow sshd_proc_t etc-ssh-ssh_config:file{open read};

[0171] allow sshd_proc_t etc-passwd:file{open}.

[0172] Optionally, the specific action specified by the subject may be determined based on the subject security label and the object security label in the security log.

[0173] Through the subject security label: sshd_proc_t and the object security labels: etc-ssh-ssh_confi and etc-passwd in the above policy rules, it can be analyzed that the process shhd performed open and read operations on the files / etc / ssh / ssh_config and / etc / passwd.

[0174] By analyzing the security log by the second terminal, an update strategy can be determined to dynamically update the SELinux strategy, improve the SELinux strategy, increase the effectiveness of the SELinux strategy, and reduce the difficulty of using the SELinux strategy.

[0175] Based on the same application concept, the embodiments of the present application also provide a SELinux policy construction device corresponding to the SELinux policy construction method. Since the principle of solving the problem by the device in the embodiments of the present application is similar to that of the aforementioned SELinux policy construction method embodiment, the implementation of the device in this embodiment can refer to the description in the embodiment of the above method, and the repeated parts will not be repeated.

[0176] See also Figure 7 , is a schematic diagram of the functional modules of the SELinux policy construction device provided in an embodiment of the present application. The modules in the SELinux policy construction device in this embodiment are used to execute the various steps in the above method embodiment. The SELinux policy construction device includes: a second receiving module 610 and a second generating module 620; the contents of each module are as follows:

[0177] The second receiving module 610 is configured to receive a security log sent by a client, wherein the security log is a security log generated by the client when testing the software to be monitored based on the initial policy;

[0178] The second generating module 620 is configured to generate an update policy according to the security log, and send the update policy to the client, so that the client can use the update policy to update the current policy.

[0179] In a possible implementation, the security log carries a subject security label and an object security label;

[0180] The second generating module 620 is configured to generate an update policy according to the subject security label and the object security label, wherein the update policy includes subject information, object information, and an action of the subject on the object.

[0181] In addition, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the SELinux policy construction method described in the above method embodiment are executed.

[0182] The computer program product of the SELinux policy construction method provided in the embodiments of the present application includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the steps of the SELinux policy construction method described in the above method embodiments. For details, please refer to the above method embodiments and will not be repeated here.

[0183] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0184] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0185] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk. It should be noted that, in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0186] The foregoing description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

[0187] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A SELinux policy construction method, characterized in that: include: Generate the subject initial policy according to the path of the executable file of the software to be monitored; Generating an object initialization policy based on the path of the target file to be monitored by the executable file of the software to be monitored, including: if the number of directories in the path of the target file to be monitored by the executable file of the software to be monitored is greater than N1, determining N-level directories, wherein N1 is a positive integer greater than 1; determining an object security label based on the N-level directories and the file names of the subdirectories in the N-level directories; wherein the subject initialization policy and the object initialization policy form an initial policy; Based on the initial strategy, the software to be monitored is tested to obtain security logs generated during the testing process; Sending the security log to the server, so that the server can generate an update strategy based on the security log; Receive the update policy sent by the server, and use the update policy to update the current policy, wherein when the policy is updated for the first time, the current policy is the initial policy.

2. The method according to claim 1, characterized in that The subject initial policy includes a subject security label; The generating of the subject initial strategy according to the path of the executable file of the software to be monitored includes: Determine the main process name based on the path of the executable file of the software to be monitored; According to the subject process name, a subject security label in the subject initial policy is determined.

3. The method according to claim 1, characterized in that The object initialization policy includes an object security label; The generating of the object initialization policy according to the path of the target file to be monitored by the executable file of the software to be monitored includes: Determine the file name and one or more levels of directories based on the path of the target file to be monitored by the executable file of the software to be monitored; An object security label is determined based on the file name and one or more levels of directories.

4. The method according to claim 1, wherein The object initialization policy includes an object security label; The generating of the object initialization policy according to the path of the target file to be monitored by the executable file of the software to be monitored includes: If the total number of files in the path of the target files to be monitored by the executable file of the software to be monitored is greater than N2, N3 target files are determined, where N2 is a positive integer greater than 1, and N3 is a positive integer less than or equal to N2; According to the paths of the N3 target files, object security labels corresponding to the N3 target files are determined.

5. The method according to claim 1, wherein The subject initial policy includes a mode field and a risk flag. The mode field is used to mark the current operating mode of the subject corresponding to the subject initial policy; the risk flag is used to mark the behavior processing method of the subject corresponding to the subject initial policy; The method further includes: for any target subject initial policy, processing the target subject behavior corresponding to the target subject initial policy according to the actual values ​​of the mode field and the risk flag.

6. The method according to claim 5, characterized in that The operation modes include: learning mode, mixed mode and forced mode, and the value of the risk flag includes a first value and a second value; The processing of the target subject behavior corresponding to the target subject initial policy according to the mode field and the actual value of the risk flag bit includes: If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in learning mode, the illegal behavior of the target subject corresponding to the target subject's initial policy is allowed and recorded in the security log; If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in a mandatory mode, intercept the illegal behavior of the target subject corresponding to the target subject's initial policy and record it in a security log; If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in a mixed mode, and the actual value of the risk flag is the first value, intercept the illegal behavior of the target subject corresponding to the target subject's initial policy and record it in a security log; If the actual value of the mode field in the target subject's initial policy indicates that the target subject is in mixed mode, and the actual value of the risk flag is the second value, the illegal behavior of the target subject corresponding to the target subject's initial policy is released and the security log is recorded.

7. A SELinux policy construction device, characterized in that: include: A first generating module, configured to generate an initial strategy according to the path of the executable file of the software to be monitored; A testing module, configured to test the software to be monitored based on the initial policy to obtain security logs generated during the testing process; A first sending module, configured to send the security log to a server, so that the server generates an update strategy according to the security log; a first receiving module, configured to receive the update policy sent by the server, and use the update policy to update the current policy, wherein when the policy is updated for the first time, the current policy is the initial policy; Among them, the first generation module is also used to generate a subject initial policy according to the path of the executable file of the software to be monitored, and generate an object initial policy according to the path of the target file that the executable file of the software to be monitored needs to monitor; wherein, the subject initial policy and the object initial policy form an initial policy; wherein, the above-mentioned generation of the object initial policy according to the path of the target file that the executable file of the software to be monitored needs to monitor includes: if the number of directories in the path of the target file that the executable file of the software to be monitored needs to monitor is greater than N1, determine the N-level directory, wherein N1 is a positive integer greater than 1; determine the object security label according to the N-level directory and the file name of the subdirectory in the N-level directory.

8. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the machine-readable instructions are executed by the processor to perform the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, executes the steps of the method according to any one of claims 1 to 6.

Images