CN115481421A

CN115481421A - SELinux strategy construction method and device, electronic equipment and readable storage medium

Info

Publication number: CN115481421A
Application number: CN202211212280.3A
Authority: CN
Inventors: 刘超; 胡亚运
Original assignee: Beijing Topsec Technology Co Ltd; Beijing Topsec Network Security Technology Co Ltd; Beijing Topsec Software Co Ltd; Hubei Topsec Network Security Technology Co Ltd
Current assignee: Beijing Topsec Technology Co Ltd; Beijing Topsec Network Security Technology Co Ltd; Beijing Topsec Software Co Ltd; Hubei Topsec Network Security Technology Co Ltd
Priority date: 2022-09-30
Filing date: 2022-09-30
Publication date: 2022-12-16

Abstract

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

Description

SELinux strategy construction method and device, electronic equipment and readable storage medium

Technical Field

The application relates to the field of computer security, in particular to a SELinux policy construction method and device, electronic equipment and a readable storage medium.

Background

SELinux (Security-Enhanced Linux) is an implementation mode for forcibly accessing and controlling MAC, and SELinux implements control over a main behavior through a policy rule.

Disclosure of Invention

The application aims to provide a SELinux strategy construction method, a SELinux strategy construction device, electronic equipment and a readable storage medium, so as to solve the problem that SELinux strategy rules are difficult to develop and maintain.

In a first aspect, the present invention provides a SELinux policy construction method, including: generating an initial strategy according to the path of an executable file of the software to be monitored; testing the software to be monitored based on the initial strategy to obtain a security log generated in the testing process; sending the security log to a server side so that the server side can generate an updating strategy according to the security log; and receiving the updating strategy sent by the server, and updating the current strategy by using the updating strategy, wherein the current strategy is the initial strategy when the strategy is updated for the first time.

In an optional embodiment, the generating an initial policy according to a path of an executable file of software to be monitored includes: generating a main body initial strategy according to the path of an executable file of the software to be monitored; and generating an object initial strategy according to the path of the target file to be monitored of the executable file of the software to be monitored.

In the above embodiment, the initial policy includes a subject initial policy and an object initial policy, so that the subject and the object can be better marked respectively, and the behavior of the subject and the positioning of the action object of the subject behavior can be better realized through the subject initial policy and the object initial policy.

In an alternative embodiment, the subject initial policy comprises a subject security label; the generating of the main body initial strategy according to the path of the executable file of the software to be monitored comprises the following steps: determining a main process name according to the path of an executable file of the software to be monitored; and determining the main body security label in the main body initial strategy according to the main body process name.

In the above embodiment, the process name can be directly presented in the security tag of the main body, and the main body can be better located, so that the main body operation can be recorded in the security log.

In an alternative embodiment, the object initiation policy comprises an object security tag; the generating an object initial policy according to the path of the target file to be monitored of the executable file of the software to be monitored comprises the following steps: determining a file name and a one-level or multi-level directory according to a path of a target file to be monitored of the executable file of the software to be monitored; and determining the object security label according to the file name and the one-level or multi-level directory.

In the embodiment, the absolute path of the object can be reversely deduced according to the object security tag, so that the file acted by the object can be conveniently positioned, and the operation of the object can be analyzed more accurately.

In an alternative embodiment, the object initiation policy comprises an object security tag; the generating an object initial policy according to the path of the target file to be monitored of the executable file of the software to be monitored comprises the following steps: if the number of directories in the path of the target file required to be monitored by the executable file of the software to be monitored is larger than N1, determining N1-level directories, wherein N1 is a positive integer larger than 1; and determining the object security label according to the N-level directory and the file names of the subdirectories in the N1-level directory.

In the above embodiment, the object initiation policy includes an object security tag;

the generating an object initial policy according to the path of the target file to be monitored of the executable file of the software to be monitored comprises the following steps: if the total number of files in the path of the target file required to be monitored by the executable file of the software to be monitored is greater than N2, determining N3 target files, wherein N2 is a positive integer greater than 1, and N3 is a positive integer less than or equal to N2; and determining object security labels corresponding to the N3 target files according to the paths of the N3 target files.

In the above embodiment, the number of directories or the total number of files in a path of a file of an object may also be identified, and when the number is too large, a large number of object security tags are avoided, and a part of directories may be appropriately extracted to generate the object security tags, thereby improving the initial policy generation efficiency.

In an optional embodiment, the initial policy of the body includes a mode field and a risk flag, where the mode field is used to mark a current operation mode of the body corresponding to the initial policy of the body; the risk flag bit is used for marking a behavior processing mode of the main body corresponding to the main body initial strategy; the method further comprises the following steps: and aiming at any one target subject initial strategy, processing the subject behavior corresponding to the target subject initial strategy according to the mode field and the actual value of the risk flag bit.

In the above embodiment, different motion modes of the main body may be further set to adapt to policy construction at different schedules, and the improvement of the policy can be further achieved while maintaining the security of the device.

In an alternative embodiment, the operating modes include: the risk flag bit value comprises a learning mode, a mixed mode and a forcing mode, wherein the risk flag bit value comprises a first value and a second value;

the processing 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 initial strategy of the target subject indicates that the target subject is in a learning mode, releasing illegal behaviors of the target subject corresponding to the initial strategy of the target subject, and recording a safety log;

if the actual value of the mode field in the initial strategy of the target subject indicates that the target subject is in a forced mode, intercepting illegal behaviors of the target subject corresponding to the initial strategy of the target subject, and recording a security log;

if the actual value of the mode field in the target main body initial strategy represents that the target main body is in a mixed mode and the actual value of the risk flag bit is a first value, intercepting illegal behaviors of the target main body corresponding to the target main body initial strategy and recording a security log;

and if the actual value of the mode field in the initial strategy of the target main body indicates that the target main body is in a mixed mode and the actual value of the risk flag bit is a second value, releasing illegal behaviors of the target main body corresponding to the initial strategy of the target main body and recording a safety log.

In the above embodiment, multiple operation modes and the value of the risk flag may be set, and the limitation on the operation of the subject may be adjusted by adjusting the field in the target subject initial policy, so as to use the requirements in different scenarios.

In a second aspect, the present invention provides a SELinux policy construction method, including:

receiving a security log sent by a client, wherein the security log is generated by testing software to be monitored by the client based on an initial strategy;

and generating an updating strategy according to the security log, and sending the updating strategy to the client so that the client can update the current strategy by using the updating strategy.

In an alternative embodiment, the security log carries a subject security tag and an object security tag;

the generating an update policy according to the security log includes: and generating an updating strategy according to the subject security label and the object security label, wherein the updating strategy comprises subject information, object information and the action of the subject on the object.

In a third aspect, the present invention provides a SELinux policy construction apparatus, including:

the first generation module is used for generating an initial strategy according to the path of the executable file of the software to be monitored;

the testing module is used for testing the software to be monitored based on the initial strategy so as to obtain a security log generated in the testing process;

the first sending module is used for sending the security log to a server so that the server can generate an updating strategy according to the security log;

and the first receiving module is used for receiving the updating strategy sent by the server and updating the current strategy by using the updating strategy, wherein the current strategy is the initial strategy when the strategy is updated for the first time.

In a fourth aspect, the present invention provides a SELinux policy construction apparatus, including:

the second receiving module is used for receiving a security log sent by the client, wherein the security log is generated by testing the software to be monitored based on the initial strategy by the client;

and the second generation module is used for generating an update strategy according to the security log and sending the update strategy to the client so that the client can update the current strategy by using the update strategy.

In a fifth aspect, the present invention provides an electronic device, comprising: a processor, a memory storing machine-readable instructions executable by the processor, the machine-readable instructions when executed by the processor performing the steps of the method of any of the preceding embodiments when the electronic device is run.

In a sixth aspect, the present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the method according to any of the preceding embodiments.

The beneficial effects of the embodiment of the application include: by automatically generating the initial strategy, the requirement on a developer can be reduced in the SELinux strategy construction process, and the initial strategy generation efficiency can also be improved. Further, an update strategy can be generated based on a security log generated by testing of software to be monitored so as to perfect the SELinux strategy, and the difficulty of developing and maintaining the SELinux strategy rule is reduced under the condition that the security of the operating system is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.

Fig. 1 is a schematic diagram illustrating interaction between a first terminal and a second terminal according to an embodiment of the present application;

fig. 2 is a block diagram of an electronic device according to an embodiment of the present disclosure;

fig. 3 is a flowchart of a SELinux policy construction method provided in the embodiment of the present application;

fig. 4 is an optional flowchart of step 310 of the SELinux policy construction method provided in the embodiment of the present application;

fig. 5 is a schematic functional module diagram of a SELinux policy constructing apparatus according to an embodiment of the present application;

fig. 6 is a flowchart of another SELinux policy construction method provided in the embodiment of the present application;

fig. 7 is a schematic functional module diagram of another SELinux policy constructing apparatus according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not construed as indicating or implying relative importance.

Mandatory access control, MAC (MAC), in the field of computer security refers to an access control that is constrained by an operating system with the goal of limiting subject access or the ability to perform some operation on an object. The main body is usually a process or a thread, and the object may be a file, a directory, a TCP (Transmission Control Protocol)/UDP (User Datagram Protocol) port, a shared memory segment, an I/O (Input/Output) device, or the like. SELinux (Security-Enhanced Linux) is an implementation manner for mandatory access control MAC.

The SELinux realizes control over the main behavior through a policy rule, and has two operation modes, namely a learning mode and a forcing mode. In the mandatory mode, if the process behavior violates the policy rule, the current behavior is intercepted; the behavior of the process violating the policy rules in the learning mode is not intercepted, but is recorded by a SELinux log. These log records may be used to assist in developing SELinux policy rules. The prior development work of the current SELinux strategy rules is mainly completed by SELinux research personnel, the development process is complex, and the later development work is generally completed based on a SELinux log application tool. Because the white list implementation mechanism of SELinux (intercepts all behaviors that are not authorized in the policy rule), when the policy rule is not completely developed, some normal behaviors of the device may be caused but the policy rule is not listed in the white list, and interception may occur, so that more exceptions may exist in the device.

Based on the above research, in order to solve the problem that the construction and use of the SELinux policy are complex, the SELinux policy construction method, apparatus, electronic device, and readable storage medium provided by the present application are described below with some embodiments.

To facilitate understanding of this embodiment, first, a detailed description is given of an operating environment for executing the SELinux policy construction method disclosed in this embodiment of the present application.

Fig. 1 is a schematic diagram illustrating interaction between a first terminal 110 and a second terminal 120 according to an embodiment of the present disclosure. The second terminal 120 is communicatively coupled to one or more first terminals via a network for data communication or interaction. The second terminal 120 may be a web server, a database server, or the like, or may be a Personal Computer (PC), a tablet computer, a smart phone, a Personal Digital Assistant (PDA), or the like. The first terminal 110 may be a Personal Computer (PC), a tablet PC, a smart phone, a Personal Digital Assistant (PDA), and the like.

In this embodiment, the latest SELinux policy may be stored in the first terminal 110, and the first terminal may control a main behavior of the first terminal based on the SELinux policy. A client may also be deployed in the first terminal. The client may receive the SELinux policy and update the local policy.

The second terminal 120 may be deployed with a server, and after the client and the server can establish a link, the client may send the SELinux security log to the server.

In one example, the client deployed in the first terminal 110 may be an rsyslogd client, and the server deployed in the second terminal 120 may be an rsyslogd server. After the rsyslogd client establishes a link with the rsyslogd server, the security log of the SELinux can be sent to the rsyslogd server through the rsyslogd client.

The first terminal 110 and the second terminal 120 shown in fig. 1 may be electronic devices having a storage function and a processing function. As shown in fig. 2, the electronic device 200 may include a memory 211, a processor 213. It will be understood by those skilled in the art that the structure shown in fig. 2 is merely illustrative and is not intended to limit the structure of the electronic device 200. For example, electronic device 200 may also include more or fewer components than shown in FIG. 2, or have a different configuration than shown in FIG. 2.

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

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 Read-Only Memory (EPROM), an electrically Erasable Read-Only Memory (EEPROM), and the like. The memory 211 is configured to store a program, and the processor 213 executes the program after receiving an execution instruction, and the method performed by the electronic device 200 defined by the process disclosed in any embodiment of the present application may be applied to the processor 213, or implemented by the processor 213.

The processor 213 may be an integrated circuit chip having signal processing capability. The Processor 213 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the Integrated Circuit may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The electronic device 200 in this embodiment may be configured to perform each step in each method provided in this embodiment. The implementation process of the SELinux policy construction method is described in detail below by several embodiments.

Please refer to fig. 3, which is a flowchart of a SELinux policy construction method according to an embodiment of the present application. The steps in the method of this embodiment may be executed by the first terminal shown in fig. 1, or may be executed by a client running in the first terminal. The specific flow shown in fig. 3 will be described in detail below.

Step 310, generating an initial policy according to the path of the executable file of the software to be monitored.

In this embodiment, the initial policy may include a main initial policy of a process of the software to be monitored, which needs to be monitored. The initial policy may also include an object initial policy of an object that the software to be monitored needs to operate. The object may be a file, directory, etc. of the desired operation of the software to be monitored.

Alternatively, an initial policy may be generated from the path of the executable file of the software to be monitored using a policy generation tool. For example, the path of the executable file of the software to be monitored may be an absolute path of the executable file of the software to be monitored.

Illustratively, the policy generation tool may be get _ policy _1.0, and the policy generation tool get _ policy _1.0 may generate the initial policy according to the path of the executable file of the software to be monitored in the specified file by storing the path of the executable file of the software to be monitored in the specified file and then executing the policy generation tool get _ policy _ 1.0.

In one example, the designated file may be selinux _ process. Conf, which may receive the path of the executable file for all software that needs to be monitored. The path configured in the specified file selinux _ process. Conf can be set as needed.

And step 320, testing the software to be monitored based on the initial strategy to obtain a security log generated in the testing process.

For example, the software to be monitored may be tested using a test case to generate a security log during the testing process. The security log may record process information of the software to be monitored, and operations executed by the process.

Illustratively, the security log may be a SELinux intercept log.

Step 330, sending the security log to a server, so that the server generates an update policy according to the security log.

Illustratively, the server may generate the update policy from the security log after receiving the security log.

In one example, an audio 2allow tool may be used to generate a particular policy rule from a security log.

Step 340, receiving the update policy sent by the server, and updating the current policy by using the update policy.

Wherein, when the strategy is updated for the first time, the current strategy is the initial strategy. With the updating of the policy in the client, the current policy can be continuously refined.

In this embodiment, by automatically generating the initial policy, the requirement on the developer can be reduced in the SELinux policy construction process, and the initial policy generation efficiency can also be improved. Further, an update strategy can be generated based on a security log generated by testing of software to be monitored so as to perfect the SELinux strategy, and the difficulty of developing and maintaining the SELinux strategy rule is reduced under the condition that the security of the operating system is improved.

The functions running in the software to be monitored are considered, and besides the function of the execution main body, the functions also comprise objects under the function of the execution main body. Based on this, the initial policy may include a subject initial policy and a subject initial policy. As shown in fig. 4, step 310 may include step 311 and step 312.

Step 311, generating a main body initial policy according to the path of the executable file of the software to be monitored.

Illustratively, the principal initialization policy includes a principal security label.

The step 311 may include: determining a main process name according to the path of an executable file of the software to be monitored; and determining the main body security label in the main body initial strategy according to the main body process name.

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

If the host process name that can be extracted from the instance/usr/sbin/ntpd is ntpd, the host security tag can be generated according to the process name ntpd. If the main process name that can be extracted from the instance/usr/local/sbin/sshd is sshd, a main security label can be generated according to the process name sshd.

Illustratively, a designated character may be added on the basis of the process name to obtain the subject security label. In one example, the designated character may be proc _ t.

Taking the above two examples as examples, the resulting subject security labels are ntpd _ proc _ t and sshd _ proc _ t, respectively.

In this embodiment, a policy generation tool get _ policy _1.0 may be used, and a security label may be automatically generated for a process of software to be monitored based on a rule of "subject security label = process name + proc _ t", and a policy rule may be generated at the same time.

In one example, the policy rule may be: type _ transition source _ type target _ type process _ type;

wherein, source _ type represents the set of all process security labels in the system, and target _ type represents the security label of the executable file corresponding to the process; process _ type represents a process security label.

Through the security tag configuration, any parent process can be ensured to use the expected security tag when executing the specified executable program.

Step 312, generating an object initial policy according to the path of the target file to be monitored of the executable file of the software to be monitored.

In this embodiment, the object initial policy includes an object security tag.

Optionally, the absolute path of the file for which the object security label needs to be set may be configured in the designated file, so that the policy generation tool get _ policy _1.0 may be used to automatically scan the absolute path in the designated file, and generate the object security label corresponding to each file.

In one embodiment, step 312 may include: determining a file name and a one-level or multi-level directory according to a path of a target file required to be monitored by an executable file of the software to be monitored; and determining the object security label according to the file name and the one-level or multi-level directory.

And determining the number of the levels of the directories of the target files according to the storage positions of the target files.

Optionally, the policy generation tool get _ policy _1.0 may automatically scan the absolute path of the file related to the software to be monitored, and automatically generate the object initial policy. Optionally, the policy generation tool get _ policy _1.0 may automatically scan the absolute path of the file to be monitored by the software to be monitored, and automatically generate the object initial policy.

Exemplarily, the object security label = file name root directory-file name secondary root-file name, wherein the hierarchy of the file directory may be determined according to the file storage location.

For example, the absolute path of a file to be monitored is: and/etc/password, the object security label of the file is as follows: etc. of the protein. As another example, the absolute path of a file to be monitored: and/etc/ssh/ssh _ config, the object security label of the file is: etc-ssh-ssh _ config.

Optionally, the absolute path of the file to be monitored may be configured in the specified file in advance, and the policy generation tool get _ policy _1.0 may automatically scan the absolute path of each file in the specified file to automatically generate the object initial policy. Conf is the designated file selinux _ file.

Alternatively, when a file name under the parent directory is not written into the designated file, the file under the parent directory may use a security tag based on the parent directory name by default.

In one example, a parent directory includes a plurality of files, which are respectively A/B/F1/F11, A/B/F1/F12, and A/B/F1/F13. However, if the absolute paths of F11, F12, and F13 are not configured in the designated file, the object security tags specified by the files F11, F12, and F13 may not be generated, and only the object security tag of the parent directory a/B/F1 may be generated. The object security tag for parent directory A/B/F1 may be expressed as: A-B-F1. The child files under the parent directory a/B/F1 may each use the object security tag of the parent directory.

In some practical scenarios, the number of files related to software to be monitored may be large, or directory hierarchies where the related files are located are deep, and if object security tags are set for all files, a configuration amount may be large, and a large number of generated object security tags may be generated. Based on this, step 312 may include: if the number of the directories in the path of the target file required to be monitored by the executable file of the software to be monitored is larger than N1, determining the directory of the N1 level, and determining the object security label according to the directory of the N1 level and the file names of the subdirectories in the directory of the N level.

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

For example, if the N-level directory includes M sub-directories, M object security tags may be generated under the N-level directory.

If a plurality of directories or files are also included under the M sub-directories, the M object security tags are all used by the plurality of directories or files under the M sub-directories.

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

For the remaining target files except the above N3 target files, the object security tag of its parent directory may be used.

Where N2 can be set as needed, for example, N2 can be 20, 50, 100, 150, etc.

Illustratively, the selection of the N3 target files may be set by the user according to the actual access frequency or access requirement. For example, the user may configure the N3 object files in a designated file. The policy generation tool get _ policy _1.0 may automatically scan the absolute paths of the N3 target files in the designated file to automatically generate the object security label.

Illustratively, the N3 target files may be determined according to other criteria. For example, the root directory may be selected first, and the directories are deepened sequentially until N3 target files are selected. For another example, N3 object files may be randomly selected. In practical cases, the mode of selecting N3 target files may be set according to requirements.

In one embodiment, step 312 may include: aiming at any specified directory to be monitored by the software to be monitored, if the number of files in the specified directory is larger than the set number, an object security label can be set for the specified directory.

The files or subdirectories under the specified directory may each use the object security label for the specified directory.

Through the configuration mode, a proper amount of object security tags can be set for the files of the objects, a large number of object security tags are avoided, partial catalogs can be properly extracted to generate the object security tags, and the initial strategy generation efficiency is improved.

In order to enable the SELinux policy construction method to be applicable to more application scenarios, for example, a mandatory mode may be used for some processes that have already completed policy rules, so that security of a device using the SELinux policy is guaranteed, a learning mode may be used for some processes that still need to be completed, so that the processes may also continue to complete policy rules, and abnormal interception of the processes by the device using the SELinux policy may not be caused. Therefore, multiple operation modes can also be set for the SELinux policy.

Optionally, the initial policy of the body includes a mode field and a risk flag, where the mode field is used to mark a current operation mode of the body corresponding to the initial policy of the body; the risk flag is used for marking the behavior processing mode of the main body corresponding to the main body initial strategy.

The SELinux policy construction method in this embodiment may further include: and aiming at any one target main body initial strategy, processing the main body behavior corresponding to the target main body initial strategy according to the mode field and the actual value of the risk zone bit.

Illustratively, the operational modes include: the risk flag comprises a learning mode, a mixed mode and a forcing mode, and the value of the risk flag comprises a first value and a second value.

In one example, the mode field may be represented as: is _ mixed.

And if the actual value of the mode field in the initial strategy of the target subject indicates that the target subject is in a learning mode, releasing the illegal behavior of the target subject corresponding to the initial strategy of the target subject, and recording a safety log.

If the actual value of the mode field in the initial strategy of the target main body indicates that the target main body is in a mandatory mode, intercepting illegal behaviors of the target main body corresponding to the initial strategy of the target main body, and recording a security log.

Illustratively, a partially learned policy rule process may be configured into a forced mode. For example, the mandatory mode may be configured in a specified file. For example, in the absolute path of a process in the selinux _ process.conf file: and/usr/sbin/ntpd equation. At this time, the process ntpd is set to the mandatory mode, so that the illegal action of the process product can be intercepted, and an interception log is generated.

If the actual value of the mode 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 bit is a first value, intercepting illegal behaviors of the target subject corresponding to the initial policy of the target subject and recording a security log.

And if the actual value of the mode field in the initial strategy of the target main body indicates that the target main body is in a mixed mode and the actual value of the risk flag bit is a second value, releasing illegal behaviors of the target main body corresponding to the initial strategy of the target main body and recording a security log.

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

Alternatively, the actual value of the mode field may be three values, each corresponding to an operating mode. In one example, when the actual value of the mode field is 0, the operation mode is the learning mode; when the actual value of the mode field is 1, the operation mode is a mixed mode; when the actual value of the mode field is 2, the operation mode is the forced mode.

The illegal behavior processing mode for the subject in different modes is represented by a table as follows:

is _ mixed value	High risk zone bit	Illegal action processing result
			0 (learning mode)	0	Generating SElinux security log to release illegal behaviors
0 (learning mode)	1	Generating SElinux security log and releasing illegal behaviors
			1 (Mixed mode)	0	Generating SElinux security log and releasing illegal behaviors
1 (Mixed mode)	1	Generating SElinux security log and intercepting illegal behaviors
			2 (force mode)	0	Generating SElinux security log and intercepting illegal behaviors
2 (force mode)	1	Generating SElinux security log and intercepting illegal behaviors

Alternatively, the security log generated in the hybrid mode may be divided into an interception log and a learning log, for example, a log generated for a process with a high risk flag bit of 0 is determined as the learning log, and a log generated for a process with a high risk flag bit of 1 is determined as the interception log.

The learning log can be used for continuously perfecting the policy rules, and specific illegal behaviors of the process can be analyzed based on the interception log.

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

The SELinux policy construction method of the embodiment can be applied to all operating systems based on linux kernels.

In this embodiment, security reinforcement of the current operating system is required, a process that needs to run on the device for a long time may be screened out first to perform behavior control, then an absolute path of an executable file corresponding to the process that needs to be monitored may be configured in a specified file selinux _ process.conf, and finally, based on an interception behavior log generated by daily testing, a policy rule of the processes is automatically generated based on the interception behavior log by using an audio 2allow tool. The requirements of users on the SElinux strategy can be reduced, the learning cost of research and development personnel on the tool is reduced, the development difficulty of the SELinux strategy rules is reduced, and the use cost of the SELinux tool is reduced.

In some cases, if it cannot be guaranteed that policy rules of all processes are developed, but some processes with higher risks (such as sshd nginx mysql and the like) need to be configured into a forced mode to improve the security of the device using the SELinux policy, the SELinux mode may be configured into a mixed mode, the processes sshd, nginx and mysql are configured into the forced mode, and other processes continue to operate in a learning mode, so that the security of the device using the SELinux policy may be guaranteed, and device abnormality due to lack of policy rules may be avoided. The mixed mode can give consideration to both safety and stability, and the flexibility of the SELinux is increased, so that a user can adjust the using mode of the SELinux according to the system safety level.

Through the setting of the mixed mode, the behaviors of sshd, nginx and mysql can be limited from the kernel level, if a remote attacker invades the processes of sshd, nginx and mysql to access other confidential files on the equipment, all abnormal behaviors can be intercepted by the SELinux strategy, and the specific behavior of the attacker can be quickly positioned by a user through logs.

Furthermore, as the security tags are arranged for the subjects and the objects, the absolute paths of the objects acted by the subjects can be accurately positioned through the security tags in the security logs, and the specific information of the accessed files can be accurately positioned.

Based on the same application concept, a SELinux policy construction apparatus corresponding to the SELinux policy construction method is also provided in the embodiments of the present application, and because the principle of solving the problem of the apparatus in the embodiments of the present application is similar to that in the embodiments of the SELinux policy construction method described above, the implementation of the apparatus in the embodiments of the present application may refer to the description in the embodiments of the above method, and repeated details are not described here.

Fig. 5 is a schematic functional module diagram of a SELinux policy constructing apparatus according to an embodiment of the present application. Each module in the SELinux policy constructing apparatus in this embodiment is configured to execute each step in the foregoing method embodiment. The SELinux strategy construction device comprises: a first generating module 410, a testing module 420, a first transmitting module 430 and a first receiving module 440; the contents of each module are as follows:

a first generating module 410, configured to generate an initial policy according to a path of an executable file of software to be monitored;

the testing module 420 is configured to test the software to be monitored based on the initial policy to obtain a security log generated in a testing process;

a first sending module 430, configured to send the security log to a server, so that the server generates an update policy according to the security log;

the first receiving module 440 is configured to receive the update policy sent by the server, and update a current policy by using the update policy, where the current policy is the initial policy when the policy is updated for the first time.

In one possible implementation, the first generation module 410 includes a first generation unit and a second generation unit:

the first generating unit is used for generating a main body initial strategy according to the path of the executable file of the software to be monitored;

and the second generating unit is used for generating an object initial strategy according to the path of the target file required to be monitored by the executable file of the software to be monitored.

In one possible embodiment, the subject initial policy includes a subject security label;

the first generation unit is used for determining the name of the main process according to the path of the executable file of the software to be monitored; and determining the main body security label in the main body initial strategy according to the main body process name.

In one possible embodiment, the object initialization policy includes an object security tag;

the second generation unit is used for determining a file name and one-level or multi-level directories according to the path of the target file required to be monitored by the executable file of the software to be monitored; and determining the object security label according to the file name and the one-level or multi-level directory.

In a possible implementation manner, the second generating unit is configured to determine a directory of N1 level 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 determining the object security label according to the N1-level directory and the file names of the subdirectories in the N1-level directory.

In a possible implementation manner, the second generating unit is configured to determine N3 target files if a total number of files in a path of the target file that needs 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 determining object security labels corresponding to the N3 target files according to the paths of the N3 target files.

In a possible implementation manner, the initial policy of the body includes a mode field and a risk flag bit, where the mode field is used to mark a current operation mode of the body corresponding to the initial policy of the body; the risk flag bit is used for marking a behavior processing mode of a main body corresponding to the main body initial strategy;

the SELinux policy constructing apparatus in this embodiment may further include: and the processing module is used for processing the main body behavior corresponding to the target main body initial strategy according to the mode field and the actual value of the risk flag bit aiming at any target main body initial strategy.

In one possible embodiment, the operation mode includes: the risk zone bit comprises a learning mode, a mixed mode and a forcing mode, wherein the value of the risk zone bit comprises a first value and a second value;

the processing module is used for releasing the illegal behavior of the target main body corresponding to the initial strategy of the target main body and recording a safety log if the actual value of the mode field in the initial strategy of the target main body indicates that the target main body is in a learning mode; if the actual value of the mode field in the initial strategy of the target main body indicates that the target main body is in a forced mode, intercepting illegal behaviors of the target main body corresponding to the initial strategy of the target main body, and recording a security log; if the actual value of the mode field in the initial strategy of the target subject indicates that the target subject is in a mixed mode and the actual value of the risk flag bit is a first value, intercepting illegal behaviors of the target subject corresponding to the initial strategy of the target subject and recording a security log; and if the actual value of the mode field in the initial strategy of the target main body indicates that the target main body is in a mixed mode and the actual value of the risk flag bit is a second value, releasing illegal behaviors of the target main body corresponding to the initial strategy of the target main body and recording a security log.

Please refer to fig. 6, which is a flowchart of a SELinux policy construction method according to an embodiment of the present application. The steps in the method of this embodiment may be executed by the second terminal shown in fig. 1, and may also be executed by a server running in the second terminal. The specific flow shown in fig. 6 will be described in detail below.

Step 510, receiving a security log sent by the client.

The security log is generated by testing the software to be monitored by the client based on an initial strategy.

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

Step 520, generating an update policy according to the security log, and sending the update policy to the client, so that the client can update the current policy by using the update policy.

Alternatively, the subject information, the object information, and the operation information performed by the subject on the object may be extracted from the security log.

An update policy may be generated based on the subject information, the object information, and the information about the operation performed by the subject on the object.

Illustratively, the security log carries a subject security tag and an object security tag.

Step 520 may include: and generating an updating strategy according to the subject security label and the object security label. The updating strategy comprises subject information, object information and actions of the subject on the object.

Optionally, the security log may be analyzed by using a specified policy generation tool to obtain the update policy. For example, the specified policy generation tool may be an audio 2allow tool.

Optionally, the absolute path of the object may be determined according to the object security label, and the host process may be determined according to the host security label.

In one example, the security log may be as follows:

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

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:s0 tcontext＝system_u:object_r:etc-passwd:s0 tclass＝file permissive＝1

through the analysis of the safety log, the main safety label can be determined as follows: sshd _ proc _ t, guest security tag is: etc. -ssh-ssh _ confi and etc-passswd.

Based on the two logs, two update policy rules are obtained by using an audio 2allow tool as follows:

allow sshd_proc_t etc-ssh-ssh_config:file{open read}；

allow sshd_proc_t etc-passwd:file{open}。

optionally, the specific action specified by the subject may also be determined based on the subject security tag and the object security tag in the security log.

By the subject security label in the policy rule: sshd _ proc _ t and object security tag: the etc-ssh-ssh _ confi and etc-passswd analyze that the process shhd carries out open and read operations on the files/etc/ssh/ssh _ config and/etc/passswd.

Through the analysis of the second terminal on the security log, the updating strategy can be determined, so that the SELinux strategy can be dynamically updated, the SELinux strategy is perfected, the effectiveness of the SELinux strategy is improved, and the difficulty in using the SELinux strategy is reduced.

Fig. 7 is a schematic functional module diagram of a SELinux policy constructing apparatus according to an embodiment of the present application. Each module in the SELinux policy constructing apparatus in this embodiment is configured to execute each step in the foregoing method embodiment. The SELinux strategy construction device comprises: a second receiving module 610 and a second generating module 620; the contents of each module are as follows:

the second receiving module 610 is configured to receive a security log sent by a client, where the security log is generated by testing software to be monitored based on an initial policy by the client;

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 updates the current policy by using the update policy.

In one possible embodiment, the security log carries a subject security tag and an object security tag;

a second generating module 620, configured to generate an update policy according to the subject security tag and the object security tag, where the update policy includes subject information, object information, and an action of the subject on the object.

In addition, an embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the SELinux policy construction method in the foregoing method embodiment are executed.

The computer program product of the SELinux policy construction method provided in the embodiment of the present application includes a computer-readable storage medium storing a program code, where instructions included in the program code may be used to execute steps of the SELinux policy construction method described in the above method embodiment, which may be specifically referred to in the above method embodiment and are not described herein again.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative and, for example, the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes. It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising 8230; \8230;" 8230; "does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises the element.

The above description is only a preferred embodiment of the present application and is not intended to limit the present application, and various modifications and changes may be made to the present application by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A SELinux strategy construction method is characterized by comprising the following steps:

generating an initial strategy according to the path of an executable file of software to be monitored;

testing the software to be monitored based on the initial strategy to obtain a safety log generated in the testing process;

sending the security log to a server side so that the server side can generate an updating strategy according to the security log;

and receiving the updating strategy sent by the server, and updating the current strategy by using the updating strategy, wherein the current strategy is the initial strategy when the strategy is updated for the first time.

2. The method of claim 1, wherein generating an initial policy according to a path of an executable file of the software to be monitored comprises:

generating a main body initial strategy according to the path of an executable file of software to be monitored;

and generating an object initial strategy according to the path of the target file to be monitored of the executable file of the software to be monitored.

3. The method of claim 2, wherein the subject initiation policy comprises a subject security label;

the generating of the main body initial strategy according to the path of the executable file of the software to be monitored comprises the following steps:

determining a main process name according to the path of an executable file of the software to be monitored;

and determining the main body security label in the main body initial strategy according to the main body process name.

4. The method of claim 2, wherein the object initiation policy comprises an object security tag;

the generating an object initial policy according to the path of the target file to be monitored of the executable file of the software to be monitored comprises the following steps:

determining a file name and a one-level or multi-level directory according to the path of a target file to be monitored of the executable file of the software to be monitored;

and determining the object security label according to the file name and the one-level or multi-level directory.

5. The method of claim 2, wherein the object initiation policy comprises an object security tag;

if the number of directories in the path of the target file required 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;

and determining the object security label according to the N-level directory and the file names of the subdirectories in the N-level directory.

6. The method of claim 2, wherein the object initiation policy comprises an object security tag;

if the total number of files in the path of the target file required to be monitored by the executable file of the software to be monitored is greater than N2, determining N3 target files, wherein N2 is a positive integer greater than 1, and N3 is a positive integer less than or equal to N2;

and determining object security labels corresponding to the N3 target files according to the paths of the N3 target files.

7. The method according to claim 1, wherein the initial policy of the body includes a mode field and a risk flag bit, and the mode field is used to mark a current operation mode of the body corresponding to the initial policy of the body; the risk flag bit is used for marking a behavior processing mode of a main body corresponding to the main body initial strategy;

the method further comprises the following steps: and aiming at any one target subject initial strategy, processing the subject behavior corresponding to the target subject initial strategy according to the mode field and the actual value of the risk flag bit.

8. The method of claim 7, wherein the operational mode comprises: the risk detection method comprises a learning mode, a mixed mode and a forcing mode, wherein the value of a risk flag bit comprises a first value and a second value;

9. A SELinux strategy construction method is characterized by comprising the following steps:

10. The method of claim 9, wherein the security log carries a subject security tag and an object security tag;

the generating an update policy according to the security log includes:

and generating an updating strategy according to the subject security label and the object security label, wherein the updating strategy comprises subject information, object information and actions of the subject on the object.

11. A SELinux strategy construction device is characterized by comprising the following components:

and the first receiving module is used for receiving the updating strategy sent by the server and updating the current strategy by using the updating strategy, wherein when the strategy is updated for the first time, the current strategy is the initial strategy.

12. A SELinux strategy construction device is characterized by comprising the following components:

the second receiving module is used for receiving a security log sent by a client, wherein the security log is generated by testing the software to be monitored by the client based on an initial strategy;

and the second generating module is used for generating an updating strategy according to the security log and sending the updating strategy to the client so that the client can update the current strategy by using the updating strategy.

13. An electronic device, comprising: a processor, a memory storing machine-readable instructions executable by the processor, the machine-readable instructions when executed by the processor performing the steps of the method of any one of claims 1 to 10 when the electronic device is operated.

14. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, which computer program, when being executed by a processor, performs the steps of the method according to any one of claims 1 to 10.