CN117131518A

CN117131518A - Method, system and storage medium for configuring SELinux security policy

Info

Publication number: CN117131518A
Application number: CN202310184498.0A
Authority: CN
Inventors: 贾云龙
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-02-22
Filing date: 2023-02-22
Publication date: 2023-11-28

Abstract

The application provides a method, a system and a storage medium for configuring a SELinux security policy, and relates to the field of information security. The method comprises the following steps: acquiring request information, wherein the request information comprises a reason type corresponding to a reason that a program is not executed according to expectations and AVC alarm information of the program; analyzing the request information to obtain an analysis result; generating a permission configuration scheme of the program according to the analysis result, wherein the permission configuration scheme is used for configuring a SELinux security policy file of the program and comprises permission sentences to be added and adding positions. The method provided by the embodiment of the application can automatically analyze the AVC alarm information and the reason type to obtain an accurate authority configuration scheme, and the SELinux security policy file of the program is conveniently and efficiently configured by a user based on the authority configuration scheme, so that the configuration cost is reduced, and the security of developed software is improved.

Description

Method, system and storage medium for configuring SELinux security policy

Technical Field

The present application relates to the field of information security, and in particular, to a method, a system, and a storage medium for configuring a SELinux security policy.

Background

Security-Enhanced Linux (SELinux) is a Linux kernel module and is also a Linux Security subsystem. SELinux provides security improvements by employing forced access control to processes and system resources. It can make each process have its own running area, and can give minimum access authority. Therefore, it is very necessary to integrate SELinux for access control in software development, which can effectively solve the existing security problem.

However, there is a certain threshold for SELinux knowledge, and developers in the non-information security field are very time-consuming in configuring SELinux security policy files, and have high configuration cost and are prone to error. Therefore, how to conveniently and efficiently configure the SELinux security policy file while reducing the configuration cost, and to improve the security of the developed software are the problems to be solved urgently at present.

Disclosure of Invention

The application provides a method, a system and a storage medium for configuring a SELinux security policy, which can automatically analyze AVC alarm information and reason types to obtain an accurate authority configuration scheme, and the SELinux security policy file of a program is conveniently and efficiently configured by a user based on the authority configuration scheme, so that the configuration cost is reduced, and the security of development software is improved.

In a first aspect, the present application provides a method for configuring a SELinux security policy, the method comprising: acquiring request information, wherein the request information comprises a reason type corresponding to a reason that a program is not executed according to expectations and AVC alarm information of the program; analyzing the request information to obtain an analysis result; generating a permission configuration scheme of the program according to the analysis result, wherein the permission configuration scheme is used for configuring a SELinux security policy file of the program and comprises permission sentences to be added and adding positions.

The analysis result may include a subject tag and an object tag corresponding to the program, and a rights sentence to be added.

The reason types can include an added process type, an added file type and a known host and guest added authority type.

The new process types comprise a new system service process type and a new inter-process communication process type.

The newly added file types comprise newly added virtual file types, newly added general file types and newly added attribute types.

Optionally, the request information further includes at least one of platform information, chip component information, system component information, attribute information, tag information, and path information.

The platform information refers to a platform used by a development program, the chip component information refers to a chip component version used by the development program, the system component information refers to a system component version used by the development program, the attribute information may include read attributes and/or write attributes of files, the tag information may include tag names, the path information may include file/executable file paths, and the like.

The method for configuring the SELinux security policy provided in the first aspect can automatically analyze AVC alarm information and reason types to obtain an accurate authority configuration scheme, and the SELinux security policy file of the program can be conveniently and efficiently configured by a user based on the authority configuration scheme, so that configuration cost is reduced, and security of developed software is improved.

In one possible implementation, analyzing the request information to obtain an analysis result includes: extracting preset keywords in the AVC alarm information; determining a subject label and an object label corresponding to a program according to preset keywords; and searching the authority statement to be added corresponding to the reason type in the database.

The preset key may include at least one of name, scontext, tcontext, class and permas.

In the implementation mode, the AVC alarm information is automatically analyzed, preset keywords are extracted, a subject label and an object label corresponding to a program and a permission statement to be added are determined, and a foundation is provided for generating a permission configuration scheme.

In a possible implementation manner, generating a permission configuration scheme of the program according to the analysis result includes: searching an adding position matched with a subject label and an object label corresponding to a program in a preset data table; and generating a permission configuration scheme according to the permission statement to be added and the addition position.

In the implementation mode, the generated authority configuration scheme also comprises the addition position, so that a user cannot blindly configure the SELinux security policy file of the program, the user is facilitated to conveniently and efficiently configure the SELinux security policy file of the program, the configuration cost is reduced, the manpower is saved, and the security of the developed software is improved.

In a second aspect, the present application provides a system for configuring SELinux security policies, including: the reason confirming module and the analyzing module;

the reason confirming module is used for displaying SELinux guide information and a method for acquiring AVC alarm information, the SELinux guide information is used for determining a reason type corresponding to a reason which is not executed according to expectations, and the method for acquiring the AVC alarm information is used for acquiring the AVC alarm information of the program;

the analysis module is used for determining and displaying a permission configuration scheme of the program according to AVC alarm information and reason types of the program, wherein the permission configuration scheme is used for configuring a SELinux security policy file of the program and comprises permission sentences to be added and addition positions.

According to the system for configuring the SELinux security policy, which is provided by the second aspect, through the content displayed by the reason confirmation module in the system, a user is guided to determine the reason type corresponding to the reason that the program is not executed according to expectations, and the user can be guided to extract AVC alarm information. And inputting the reason type determined by the reason confirmation module and the acquired AVC alarm information into an analysis module for processing, so as to obtain a permission configuration scheme. Based on the permission configuration scheme, a user is facilitated to conveniently and efficiently configure the SELinux security policy file of the program, so that configuration cost is reduced, and security of development software is improved.

In a possible implementation manner, the analysis module is further used for extracting preset keywords in the AVC alarm information; determining a subject label and an object label corresponding to a program according to preset keywords; searching authority sentences to be added corresponding to the reason types in a database; searching an adding position matched with a subject label and an object label corresponding to a program in a preset data table; and generating a permission configuration scheme according to the permission statement to be added and the addition position.

In the implementation mode, the AVC alarm information and the reason type are automatically analyzed to obtain an accurate authority configuration scheme, and the SELinux security policy file of the program is conveniently and efficiently configured by a user based on the authority configuration scheme, so that the configuration cost is reduced, and the security of the developed software is improved.

In a possible implementation manner, the system for configuring the SELinux security policy further includes a verification module.

The verification module is used for displaying various compiling and verifying methods, and the compiling and verifying methods are used for compiling and verifying the program after the SELinux security policy file is configured.

When the compiling verification method is used for compiling verification of the developed program process, the program can be ensured to be executed according to expectations. When the compiling and verifying method is used for compiling and verifying the program after the SELinux security policy file is configured, whether the configuration is effective or not can be verified.

In a possible implementation manner, the system for configuring the SELinux security policy further includes a knowledge presentation module.

The knowledge display module is used for displaying related knowledge of the SELinux, wherein the related knowledge comprises basic knowledge and safety knowledge of the SELinux.

A user can learn the security knowledge of the SELinux technology and the information security field through the content displayed by the knowledge display module, and know more related content of the SELinux and various reasons that the program is not executed according to expectations.

In addition, the reason confirmation module, the analysis module, the verification module and the knowledge display module in the system for configuring the SELinux security policy provided by the embodiment of the application are displayed on the Web interface, namely presented in the form of a Web page, so that a user can use the system at any time and any place without independently installing tools, plug-ins and the like, the configuration cost is reduced, and the convenience for configuring the SELinux security policy is improved. And the generation of the permission configuration scheme is an automatic process, so that manpower is liberated, and the configuration efficiency is improved.

In a third aspect, the present application provides an electronic device, including: one or more processors; one or more memories; a module in which a plurality of application programs are installed; the memory stores one or more programs that, when executed by the processor, cause the electronic device to perform the method of the first aspect and any possible implementation thereof.

In a fourth aspect, the present application provides a chip comprising a processor. The processor is configured to read and execute a computer program stored in the memory to perform the method of the first aspect and any possible implementation thereof.

Optionally, the chip further comprises a memory, and the memory is connected with the processor through a circuit or a wire.

Optionally, the chip further comprises a communication interface.

In a fifth aspect, the present application provides a computer readable storage medium having stored therein a computer program which, when executed by a processor, causes the processor to perform the method of the first aspect and any possible implementation thereof.

In a sixth aspect, the application provides a computer program product comprising: computer program code which, when run on an electronic device, causes the electronic device to perform the method of the first aspect and any possible implementation thereof.

In a seventh aspect, the present application provides a server for cooperating with an electronic device to jointly implement the method of the first aspect and any possible implementation thereof.

The technical effects obtained by the second, third, fourth, fifth, sixth and seventh aspects are similar to the technical effects obtained by the corresponding technical means in the first aspect, and are not described in detail herein.

Drawings

Fig. 1 is a flow chart of a method for configuring SELinux security policy in the related art according to the present application;

FIG. 2 is a schematic diagram of a system architecture shown in an exemplary embodiment of the present application;

fig. 3 is a schematic diagram of a hardware structure of an electronic device according to an exemplary embodiment of the present application;

FIG. 4 is a schematic diagram of a Web interface, according to an exemplary embodiment of the present application;

FIG. 5 is a schematic diagram of another Web interface shown in accordance with an exemplary embodiment of the present application;

FIG. 6 is a schematic diagram of yet another Web interface shown in accordance with an exemplary embodiment of the present application;

FIG. 7 is a schematic diagram of yet another Web interface shown in accordance with an exemplary embodiment of the present application;

fig. 8 is a flowchart of a method for configuring SELinux security policy according to an embodiment of the present application;

FIG. 9 is a flow chart of a method of configuring a SELinux security policy according to an exemplary embodiment of the present application;

FIG. 10 is a flow chart illustrating another method of configuring a SELinux security policy according to an exemplary embodiment of the present application;

FIG. 11 is a flow chart illustrating yet another method of configuring a SELinux security policy according to an exemplary embodiment of the present application;

fig. 12 is a schematic structural diagram of a chip according to an embodiment of the present application.

Detailed Description

The technical scheme of the application will be described below with reference to the accompanying drawings.

In the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, in the description of the embodiments of the present application, "plurality" means two or more than two.

The terms "first" and "second" are used below for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. In the description of the present embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

The technical scheme of the embodiment of the application can be applied to the electronic equipment, such as an operating system of the electronic equipment, for example, an Android (Android) system. But also to other operating systems, such as Linux operating systems, windows operating systems, etc., without limitation.

In order to better understand the system for configuring SELinux security policies and the method for configuring SELinux security policies provided by the embodiments of the present application, part of terms related to the embodiments of the present application are first explained below to facilitate understanding by those skilled in the art.

1. Security Enhanced Linux (Security-Enhanced Linux)

The SELinux is a Linux kernel module, is a mandatory access control (Mandatory Access Control, MAC) security system based on a Domain-Type (Domain-Type) model, and has the principle that any process wants to do anything in the SELinux system, and must configure rights in a SELinux security policy file. Where no rights are configured in the SELinux security policy file, the process does not have the rights for that operation. The SELinux adopts the forced access control mode to ensure the security of the process and the system resource. It can make each process have its own running area, and can give minimum access authority.

Each subject in the SELinux system has a Domain and each object has a Type.

The main body mainly refers to various processes, threads and the like in the electronic equipment. The object mainly refers to various system resources for communication, information sharing and storage in the electronic device, such as files, sockets, storage spaces, catalogs, shared memories and the like. Taking an electronic device as an example of a mobile phone, system resources in the mobile phone can include stored system files, storage spaces, storage directories of different storage spaces, and the like.

2、SEAndroid

SEAndroid is a subset of SELinux. When the SELinux technique is applied to an android system, the SELinux technique may also be referred to as sear.

SEAndroid is exactly the same in architecture and mechanism as SELinux. The security check of seaandroid may include content such as domain switching, type switching, process related operations, kernel related operations, file directory related operations, file system related operations, device related operations, application (APP) related operations, network related operations, inter-process communication (Inter-Process Communication, IPC) related operations, and the like.

3. Access vector cache (Access Vector Cache, AVC)

For recording all access statistics related to SELinux.

4. Program is not executed as expected

An unexpected execution of a program is an abnormal event that may occur during the execution of the program, affecting the normal execution of the program. In the embodiment of the application, the program not executing as expected may be a program running error, a program flashing back, the program not successfully executing certain operations, the program not realizing certain functions, etc.

5、treble

treble is an Android architecture for distinguishing system components (systems_ext) from chip components (vender). Generally, we call this combination of Android12 s+s, and Android13 t+t. Due to the binding of the chip component and the hardware, the splitting of google allows the Android version to be upgraded without changing the hardware driver, i.e. from s+s to s+t.

The foregoing is a simplified description of the terminology involved in the embodiments of the present application, and is not described in detail below.

With the development of electronic devices (e.g., mobile phones, smart wearable devices, tablet computers, personal computers (Personal Computer, PCs), desktop computers, notebook computers, large screen devices, smart televisions, etc.), security of electronic devices is also increasingly important. The application of the SELinux technology on the existing operating system platform greatly improves the safety of an operating system.

Taking the application of SELinux technology in an android system as an example, SELinux defaults that all processes and all system resources have no access rights, so that rights need to be configured in a SELinux security policy file first. For example, the security policy file is configured with access rights of different processes when accessing system resources, so that the different processes have different access rights, and the processes can not only smoothly execute basic functions, but also prevent the system resources from being maliciously used. On the premise of ensuring the functions of each process, the system safety can be ensured to the greatest extent by minimizing the access rights of each process.

In the related art, typically, a developer manually configures rights between various processes and system resources. Referring to fig. 1, fig. 1 is a flow chart of a method for configuring SELinux security policy in the related art according to the present application.

As shown in fig. 1, a developer compiles programs (such as a computer management control program, a system application program, and a third party application program), and the compiled programs run in an operating system of an electronic device. The operating system may query the SELinux rule base when running the program (e.g., the SELinux security policy file is a file in the source code of security Zhuo Gongcheng, which is compiled and loaded to become the SELinux rule base that can be queried in the operating system). If no policy rule corresponding to the behavior of the program is queried in the SELinux rule base (it can be understood that no corresponding authority is configured for the behavior of the program in the SELinux security policy file), the SELinux intercepts the program and generates alarm information in combination with the behavior of the program.

For example, SELinux uses access vector cache (Access Vector Cache, AVC) when querying the policy rules corresponding to the program's behavior in the SELinux rule base, and if access is denied (also called AVC denial), a denial message is recorded in a log file. The refused message is AVC alarm information.

The developer finds that the program is not executed as expected, and at this time, the developer needs to consult a security care personnel in the information security field to request to add or guide the security care personnel to add the policy rule corresponding to the behavior of the program (or, configure the corresponding authority for the behavior of the program in the SELinux security policy file).

Because of a certain threshold of the SELinux knowledge, developers in the non-information security field are very time-consuming in configuring the SELinux security policy file, and if the configuration is wrong, potential safety hazards are caused to an operating system. Moreover, the development of all programs can involve the problem of configuring SELinux authorities, and developers in the information security field need to configure authorities or guide developers in the non-information security field to configure authorities, so that a great deal of manpower is required, the configuration cost is high, the configuration is easy to make mistakes, and the configuration efficiency is low.

Therefore, how to conveniently and efficiently configure the SELinux security policy file while reducing the configuration cost, and to improve the security of the developed software are the problems to be solved urgently at present.

In view of this, the embodiment of the application provides a method for configuring SELinux security policy, which can obtain an analysis result by analyzing AVC alarm information and reason process of a program, and generate a permission configuration scheme of the program according to the analysis result. In the implementation manner, on one hand, because the AVC alarm information is the most accurate in various SELinux authority detection methods, the automatic analysis is performed based on the AVC alarm information, and the problem of the SELinux authority can be accurately reflected, so that the authority configuration scheme obtained after the analysis of the AVC alarm information is more accurate, and the safety condition caused by analysis errors can be effectively avoided. On the other hand, compared with the related art, the application comprises the addition position in the generated authority configuration scheme, so that a user cannot blindly configure the SELinux security policy file of the program, the user is facilitated to conveniently and efficiently configure the SELinux security policy file of the program, the configuration cost is reduced, the manpower is saved, and the security of the development software is improved.

The embodiment of the application also provides a system for configuring the SELinux security policy, and the overall architecture related to the system for configuring the SELinux security policy provided by the embodiment of the application is introduced below with reference to the attached drawings.

Referring to fig. 2, fig. 2 is a schematic diagram of a system architecture according to an exemplary embodiment of the present application. As shown in fig. 2, a system for configuring SELinux security policies provided by an embodiment of the present application may include an electronic device and a server. The electronic equipment is in communication connection with the server through a network so as to realize data communication or interaction between the electronic equipment and the server.

The electronic device in the embodiment of the application may be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented Reality (Augmented Reality, AR)/Virtual Reality (VR) device, a handheld computer, a notebook computer, an Ultra-Mobile Personal Computer (UMPC), a netbook, a personal digital assistant (Personal Digital Assistant, PDA) or the like. The embodiment of the application does not limit the specific type and form of the electronic equipment.

The server in the embodiment of the application can be an independent server, and can also be cloud service for providing cloud service, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, content delivery network (Content Delivery Network, CDN), basic cloud computing service such as big data and artificial intelligent platform, and the like. The embodiment of the application does not limit the specific type and form of the server.

For example, a front end interface may be displayed in the electronic device. The front-end interface is used for interacting with a user, thereby assisting the user in configuring a SELinux security policy file. In particular, the front-end interface may display a plurality of different modules, each module displaying different content.

For example, the front-end interface may display a cause confirmation module, an analysis module, a verification module, a knowledge presentation module, and the like. The reason confirmation module is used for displaying SELinux guide information and a method for acquiring AVC alarm information. The SELinux guiding information is used for determining a reason why the program is not executed according to expectations and a reason type corresponding to the reason. For example, the SELinux guide information may include various problems (such as SELinux authority problems) that may occur during the development of the program, and the SELinux guide information may further include various reasons that cause the program to perform unexpectedly, and a reason type corresponding to each reason.

The method for acquiring the AVC alarm information is used for acquiring the AVC alarm information of the program. Or, the method for acquiring the AVC alarm information is used for guiding the user to acquire the AVC alarm information of the program.

It can be understood that the SELinux guide information displayed by the reason confirmation module can assist the user to quickly determine the reason for the program not executing as expected and the reason type corresponding to the reason. The method for acquiring the AVC alarm information, which is displayed by the reason confirmation module, can guide a user to quickly extract the AVC alarm information of the program.

The analysis module is used for determining and displaying the authority configuration scheme of the program according to the AVC alarm information and the reason type of the program. The authority configuration scheme is used for configuring a SELinux security policy file of a program, and comprises an authority statement to be added and an adding position.

In one possible implementation, a user compiles a program and runs the compiled program in an operating system of the electronic device. When the user finds that the program is not executed as expected, the system for configuring the SELinux security policy configures a SELinux security policy file corresponding to the program, so that the program can be executed as expected.

For example, when a program is found to be not executed as expected, a problem that may occur when the program is queried in a cause confirmation module of the front-end interface, that is, a cause type that causes the program to be executed as expected is queried in the cause confirmation module. The reason type and the AVC alarm information are input into an analysis module, and the analysis module sends the input information to a server. The server analyzes the information to generate a permission configuration scheme, and sends the permission configuration scheme to the electronic equipment. And the electronic equipment receives the authority configuration scheme sent by the server and displays the authority configuration scheme in the analysis module. The user can configure the authority corresponding to the program in the SELinux security policy file according to the authority configuration scheme so that the program can be executed as expected.

The verification module is used for showing various compiling verification methods of the program, and the compiling verification method can be used for compiling verification of the developed program process so as to ensure that the program can be executed as expected. The compiling and verifying method can also be used for compiling and verifying the program after the SELinux security policy file is configured, so that whether the configuration is effective or not can be verified.

The knowledge display module is used for displaying related knowledge of SELinux, wherein the related knowledge comprises signature related knowledge (such as APK signature problem), SELinux basic knowledge, security knowledge and the like. A user can learn the security knowledge of the SELinux technology and the information security field through the content displayed by the knowledge display module, and know more related content of the SELinux and various reasons that the program is not executed according to expectations.

In short, the front-end interface prompts the user according to the fault of the positioning program, the specific reason of analysis and the flow of verification program (i.e. prompts the user how to operate when the program is not executed as expected). And the user is guided to transmit the information such as the AVC alarm information and the reason type to the server during the period, so that the server can analyze the AVC alarm information and the reason type conveniently, and then a permission configuration scheme is generated and sent to the electronic equipment. And the user configures the authority corresponding to the program in the SELinux security policy file by using the authority configuration scheme so that the program can be executed as expected.

The overall architecture related to the system for configuring SELinux security policy provided by the embodiment of the present application is described above with reference to the accompanying drawings, and the hardware structure of the electronic device related to the embodiment of the present application will be briefly described below with reference to the accompanying drawings.

Referring to fig. 3, fig. 3 is a schematic diagram illustrating a hardware structure of an electronic device according to an exemplary embodiment of the application.

As shown in fig. 3, the electronic device 100 may include a processor 110, a memory 120, and a computer program 130 stored in the memory 120 and executable on the processor 110.

It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer components than those shown in FIG. 3, or electronic device 100 may include a combination of some of the components shown in FIG. 3, or electronic device 100 may include sub-components of some of the components shown in FIG. 3. The components shown in fig. 3 may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and a command center of the electronic device 100, among others. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor (mobile industry processor interface, MIPI) interface, a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device 100. In other embodiments, the electronic device 100 may also employ different interfaces in the above embodiments, or a combination of interfaces.

The memory 120 may be an internal storage unit of the electronic device 100, such as a hard disk or a memory of the electronic device 100. The memory 120 may also be an external storage terminal of the electronic device 100, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the electronic device 100.

The memory 120 is used to store computer instructions and other programs and data needed by the electronic device 100. The memory 120 may also be used to temporarily store data that has been output or is to be output.

The computer program 130 may be divided into one or more modules that are stored in the memory 120 and executed by the processor 110 to accomplish various aspects of embodiments of the present application. The one or more elements may be a series of computer instruction segments capable of performing particular functions to describe the execution of the computer program 130 in the electronic device 100.

In an embodiment of the present application, the electronic device 100 may further include a display screen, which may be used to display the front-end interface. The reason confirming module, the analyzing module, the verifying module, the knowledge displaying module and the like are displayed in the front-end interface through a display screen.

In addition, above the above components, various types of operating systems are running. Such as Android (Android) systems, linux operating systems, windows operating systems, etc. This is merely illustrative and is not limiting. Applications may be installed and run on these operating systems.

The various technical solutions provided in the embodiments of the present application may be implemented in the electronic device 100 having the above-described hardware structure.

The hardware structure of the electronic device according to the embodiment of the present application is briefly described above, and a front-end interface displayed in the electronic device is described below with reference to the accompanying drawings.

It should be noted that, the front end interface may be a Web interface or an APP interface, and in the embodiment of the present application, the front end interface is illustrated by taking the Web interface as an example.

Referring to fig. 4, fig. 4 is a schematic diagram of a Web interface according to an exemplary embodiment of the present application. As shown in fig. 4, the Web interface includes a cause confirmation module, an analysis module, a verification module, and a knowledge presentation module.

The reason confirmation module included in the Web interface is described first. The reason confirming module is used for displaying SELinux guide information and a method for acquiring AVC alarm information.

The SELinux guiding information is used for determining a reason why the program is not executed according to expectations and a reason type corresponding to the reason. For example, the SELinux guide information may include various problems (such as SELinux authority problems) that may occur during the development of the program, and the SELinux guide information may further include various reasons that cause the program to perform unexpectedly, and a reason type corresponding to each reason.

For example, the user is guided to determine whether the reason why the program is not executed as expected is a SELinux authority problem through the content displayed by the reason confirmation module. If the reason why the program is not executed as expected is a SELinux authority problem, the user is further guided to determine a problem type (or a reason type) corresponding to the SELinux authority problem.

When the reason why the program is not executed as expected is SELinux authority problem, the program is intercepted by SELinux when running in the operating system, and AVC alarm information is generated. The content presented by the reason confirmation module further guides the user how to acquire the AVC warning information. For example, the method for obtaining the AVC alert information includes a storage path of the generated AVC alert information, and the user may extract the AVC alert information of the program according to the storage path.

In order to facilitate the user to quickly determine the reason that the program is not executed as expected, the content displayed by the reason confirmation module may be displayed in a form that one question guide corresponds to one answer guide. In one example, to facilitate a user's visual review of answers, the answer directions in the cause confirmation module may include specific answer content, i.e., the answers are displayed directly under their corresponding question directions. In another example, in order to provide a better browsing experience for the user in the case of more answer content, the answer guide in the reason confirmation module may also include a link, and the user may click on the link to trigger the Web interface to display an answer content interface corresponding to the link.

As shown in fig. 4, the cause confirmation module may specifically show the following:

question guideline 1 please confirm whether it is SELinux authority question?

Answer guide 1.SELinux closing method guidance。

Problem guideline 2 reason type

Answer guideline 2.SELinux cause classification。

Question guideline 3 how to get AVC alert information?

Answer guide 3.Method for acquiring AVC alarm information and instruction。

In one example, the compiled program is run in an operating system of the electronic device. When the program is not executed as expected, the user prioritizes whether the program is executed as expected due to SELinux authority problem according to the issue guideline 1.

Since SELinux has three modes selectable in a specific application, it can be prioritized whether or not the program caused by the improper mode setting of SELinux is not executed as expected.

Illustratively, three modes of SELinux are specifically as follows:

the first mode is an unavailable (Disabled) mode, also known as a shutdown mode, indicating that SELinux is completely Disabled.

The second mode is a tolerant (permission) mode, which indicates that the program will not intercept the non-compliant behavior when it occurs, but will record the intercepted behavior in a log.

The third mode is a forced (enforcement) mode, which indicates that when a program generates a behavior which does not conform to the authority, the program intercepts the behavior and records the intercepted behavior in a log to generate AVC alarm information.

After seeing problem guideline 1, the mode of the currently running SELinux can be queried. If the mode setting of SELinux is unreasonable, the mode of SELinux can be adjusted according to the "SELinux closing method guidance" in the answer guidance 1.

For example, the SELinux turning-off method guidance may include a method of turning on SELinux, a method of turning off SELinux, and a method of switching modes of SELinux. The user can adjust the mode of SELinux according to the "SELinux closing method guide" in answer guide 1.

It will be appreciated that the answer directions in this embodiment include links. As shown in fig. 4, the answer directions and the question directions are displayed in different manners (e.g., the answer directions include underlines) to facilitate the user's viewing of the question directions and clicking on the answer directions. For example, the user may click on answer guide 1, i.e., click "on"SELinux closing method guidanceAnd triggering the Web interface to display an answer content interface corresponding to the link of the answer guide 1. For example, a method of turning on SELinux, a method of turning off SELinux, and a method of switching modes of SELinux are shown in the answer content interface.

It should be understood that the answer content interface may be the interface after the current Web interface jumps, or may be a newly created interface, which is not limited thereto.

If it is determined that the program is not executed as expected due to the SELinux authority problem, the problem is not solved according to the answer guideline 1, and then the reason type corresponding to the reason for the program not executed as expected is determined according to the problem guideline 2. The cause types in the present embodiment may include a newly added problem type. The newly added problem type refers to a type corresponding to a program when the program is not executed according to expectations because of the newly added process, file, attribute, new authority added by a known host object (known host and/or object) and the like in the process of developing the program.

For example, a process is newly added in the process of developing a program, and the newly added process may cause the program to be executed unexpectedly. In this case, the newly added question type may include a newly added process type. The newly added processes may include, among other processes, a system service process (.rc service), an inter-process communication process (Hidl/Aidl). Other processes refer to processes other than the system service process and the inter-process communication process.

For another example, a file is newly added during the development of a program, which may cause the program to perform as intended. In this case, the newly added question type may include a newly added file type. The newly added files may include virtual files and general files. Virtual files refer to files that are dynamically generated when the system is running. A general file refers to a file that can be seen in a system directory, and a non-virtual file is understood to be a file that is written by a system at the time of compiling/developing.

As another example, properties are newly added during development of a program, which may result in the program not performing as intended. In this case, the newly added question type may include a newly added attribute type. Wherein the newly added attributes may include read attributes and/or write attributes of the file.

For another example, newly adding rights to a known subject and/or object during development of a program may result in the program not performing as intended. In this case, the newly added question type may include a newly added authority type (or referred to as a known host newly added authority type).

For example, the user may click on answer guide 2, i.e., click "on"SELinux cause classificationAnd triggering the Web interface to display an answer content interface corresponding to the link of the answer guide 2. For example, the answer content interface displays a new question type, where the new question type specifically includes the new process type, the new file type, the new attribute type, and the new authority type (or referred to as a known host-object new authority type) described above.

Optionally, in one possible implementation, the adding a process type further includes: the newly added system service process type, the newly added inter-process communication process type and the newly added other process types. The newly added file types further comprise: newly added virtual file types and newly added general file types.

In the development process, no matter which process, file, attribute and authority (the authority of the known host and client is newly added) is newly added, the user operates in person. When the user sees the newly added problem types displayed by the Web interface, the user can be reminded to combine the newly added contents (such as the newly added contents of a process, a file, an attribute, a right newly added by a known host and a client) in the process of developing the program, and the reason type corresponding to the reason that the program is not executed according to expectations is determined.

When the program is not executed as expected, the program is intercepted by SELinux when running in the operating system, and AVC alert information is generated. AVC alarm information of the program can be obtained according to the question guide 3 and the answer guide 3.

For example, the user may click on answer guide 3, i.e., click "on"Method for acquiring AVC alarm information and instruction"triggering the Web interface to display the answer content interface corresponding to the link of the answer guide 3. For example, the answer content interface shows how AVC alert information is specifically obtained. For example, a storage path for displaying the AVC alarm information is displayed, and the user can print the AVC alarm information with the "AVC direct" word in the log according to the direction of the storage path.

Illustratively, the obtained certain AVC alert information may be:

avc:denied{read}for path＝“/sbin/cbd”dev＝“rootfs”ino＝1182scontext＝u:r:cbd:s0tcontext＝u:object_r:rootfs:s0 tclass＝file permissive＝0

where avc represents a log type. read represents read rights. It should be appreciated that in other embodiments, other characters in { } represent other rights. For example, write in { write, write representing write rights; for another example, in { create, create represents a creation right, etc.

The condensed indicates what SELinux did, refused or allowed. path (and possibly name) represents the name of the target being accessed. dev represents the device or file system where the target is located.

The inode indicates the inode number of the target, which can be used to find the target file. scontext represents Source context, i.e. the context originally defined by SELinux, and can also be understood as a body tag. tcontext represents the Target context, i.e. the context of the current file, and can also be understood as the object tag.

tclass represents the type of object and file represents a common file. It should be appreciated that in other embodiments dir following tclass represents a directory and fd represents a file descriptor.

The AVC alarm information is complete in meaning: cbd Process lacks read rights to the file of the rootfs type.

In the reason confirmation module provided by the embodiment of the application, the SELinux guide information displayed by the reason confirmation module can assist the user to quickly determine the reason causing the program to be executed in unexpected mode and the reason type corresponding to the reason. The method for acquiring the AVC alarm information, which is displayed by the reason confirmation module, can guide a user to quickly extract the AVC alarm information of the program. When the program is not executed as expected, ideas and assistance are provided for users, and meanwhile, a foundation is provided for subsequent configuration of the SELinux security policy file.

The analysis module included in the Web interface is described below. The analysis module is used for determining and displaying the authority configuration scheme of the program according to the AVC alarm information and the reason type of the program. The authority configuration scheme is used for configuring a SELinux security policy file of a program, and comprises an authority statement to be added and an adding position.

Illustratively, the reason type determined by the reason confirmation module and the acquired AVC alert information are input to an analysis module, which sends the input information to a server. The server analyzes the reason type and the AVC alarm information to obtain a permission configuration scheme, and sends the permission configuration scheme to the electronic equipment. And the electronic equipment receives the authority configuration scheme sent by the server and displays the authority configuration scheme in the analysis module. The user can configure the authority corresponding to the program in the SELinux security policy file according to the authority configuration scheme so that the program can be executed as expected. For example, the user may add the rights statement to be added to the SELinux security policy file according to the addition location in the rights configuration scheme.

As shown in fig. 4, in order to facilitate the user to quickly input the problem type and AVC alert information, different input boxes and/or selection boxes are provided in the analysis module, and the user may input the reason type and AVC alert information in the corresponding input boxes and/or selection boxes according to the prompt. A submit button can be displayed in the analysis module, and after the reason type and the AVC alarm information are input, a user can click on the submit button to trigger a submit instruction, and the electronic equipment sends the reason type and the AVC alarm information to the server according to the submit instruction.

It will be appreciated that the information sent by the electronic device to the server is more comprehensive, and the analysis result of the server will be more accurate. Thus, in one possible implementation, the user may also input one or more of platform information, chip component information, and system component information in the analysis module based on the input of the reason type and AVC alert information. The platform information refers to a platform used by the development program, the chip component information refers to a chip component version (which can be understood as an android underlying version corresponding to the chip) used by the development program, and the system component information refers to a system component version (which can be understood as a version of the valley-singing android system) used by the development program.

Referring to fig. 5, fig. 5 is a schematic diagram of another Web interface according to an exemplary embodiment of the present application.

As shown in fig. 5, a drop-down bar is provided behind each input prompt message (i.e. the message requesting to select the reason type, requesting to select the platform, etc.), and in order to facilitate the user to quickly input the message, in the embodiment of the present application, multiple reason types, multiple platforms, multiple chip component versions, and multiple system component versions are preset in the drop-down bar respectively. The user may input the reason type, platform information, chip component information, and system component information using the drop down bar. For example, clicking the corner mark (e.g., the mark similar to the inverted triangle in fig. 5) behind the "please select the cause type" by the user pops up a drop-down option, displays a plurality of different newly added question types in the drop-down option, and the user selects the corresponding newly added question types according to the actual situation.

In addition, a corresponding input box is also arranged behind the please input AVC alarm information, and the user can copy the AVC alarm information acquired in the reason confirmation module and paste the AVC alarm information into the input box behind the please input AVC alarm information.

As shown in fig. 5, in one example, the analysis module may present a portion of the content as follows:

please select the reason type: new process type

Please select the platform: qcom

Please select the chip component version: t (T)

Please select the system component version: t (T)

Please input AVC alert information: … …

After the user inputs the information (such as the reason type, the platform information, the chip component information and the system component information), the user can click a submit button to trigger a submit command, and the electronic equipment sends the input information to the server according to the submit command. The server analyzes the received information to obtain a permission configuration scheme, and sends the permission configuration scheme to the electronic equipment.

After the electronic device receives the permission configuration scheme sent by the server, the permission configuration scheme is displayed in a display frame below a submit button as shown in fig. 5.

Optionally, in one possible implementation, when the input reason type is different, attribute information, tag information (such as a tag name), path information (such as a file/executable file path) and the like may also be input in the analysis module on the basis of inputting the reason type, AVC alert information, platform information, chip component information, and system component information. In the implementation mode, the information sent to the server by the electronic equipment is more comprehensive, the speed of generating the permission configuration scheme by the server is faster, and the accuracy is higher, so that the permission corresponding to the program is configured based on the permission configuration scheme sent by the server, the efficiency and the accuracy are higher, and the program is safer.

Referring to fig. 6, fig. 6 is a schematic diagram of yet another Web interface according to an exemplary embodiment of the present application. As shown in fig. 6, in one example, the analysis module may present a portion of the content as follows:

please select the reason type:

please select the platform:

please select the chip component version:

please select the system component version:

please input AVC alert information:

inputting a label:

please select the attribute attribution component:

please select the attribute writable component:

please select the property readable component:

after the user inputs the information (such as the reason type, the platform information, the chip component information, the system component information, the attribute information and the label information), the user can click a submit button to trigger a submit command, and the electronic equipment sends the input information to the server according to the submit command. The server analyzes the received information to obtain a permission configuration scheme, and sends the permission configuration scheme to the electronic equipment.

After the electronic device receives the permission configuration scheme sent by the server, the permission configuration scheme is displayed in a display frame below a submit button as shown in fig. 6.

Referring to fig. 7, fig. 7 is a schematic diagram of yet another Web interface according to an exemplary embodiment of the present application. As shown in fig. 7, in one example, the analysis module may present a portion of the content as follows:

Please select the reason type:

please select the platform:

please select the chip component version:

please select the system component version:

please input AVC alert information:

inputting a label:

input file/executable file path:

after the user inputs the information (such as the reason type, the platform information, the chip component information, the system component information, the label information and the path information), the user can click a submit button to trigger a submit command, and the electronic equipment sends the input information to the server according to the submit command. The server analyzes the received information to obtain a permission configuration scheme, and sends the permission configuration scheme to the electronic equipment.

After the electronic device receives the permission configuration scheme sent by the server, the permission configuration scheme is displayed in a display frame below a submit button as shown in fig. 7.

In the analysis module provided by the embodiment of the application, each piece of information of the program which is not executed according to the expectation is transmitted to the server through the analysis module, so that the server can analyze the information to obtain the authority configuration scheme of the program, and finally the authority configuration scheme is displayed in the analysis module. The configuration mode can be known by a user quickly through automatic analysis of the server and display of an analysis module without mastering the SELinux knowledge or guiding a developer in the information security field, so that the configuration cost is reduced, the manpower is saved, the SELinux security policy file of the program is configured conveniently and efficiently, the program can be executed according to expectations, and the security of the developed software is improved.

The authentication module included in the Web interface is described below. Illustratively, the verification module is used to expose a variety of compile verification methods for the program that can be used to compile verification of the developed program process to ensure that the program can perform as intended. The compiling and verifying method can also be used for compiling and verifying the program after the SELinux security policy file is configured, so that whether the configuration is effective or not can be verified.

Illustratively, a plurality of different compiling verification methods are set in advance according to various authority configuration schemes that may occur. In one possible implementation, the compile verification method may include test cases, and the plurality of compile verification methods are the plurality of test cases. The test case refers to description of a test task of a specific program, and the test scheme, method, technology and strategy are embodied. The test case content comprises a test target, a test environment, input data, test steps, expected results, test scripts and the like, and finally a test document is formed. Alternatively, a test case is a set of test inputs, execution conditions, and expected results that are formulated for a particular purpose to verify that the program is ultimately able to perform as intended.

After determining the authority configuration scheme of the program according to the analysis module, searching a compiling and verifying method matched with the authority configuration scheme in a plurality of compiling and verifying methods displayed by the verifying module, and compiling and verifying the program by using the searched compiling and verifying method. If the compiling verification is successful, the SELinux security policy file configured for the program is proved to be successful, and the program can be executed as expected. If the compiling verification fails, the SELinux security policy file configured for the program is proved to fail, and the program needs to be adjusted.

In order to facilitate the user to quickly grasp the compiling and verifying method of the program, the content displayed by the verifying module is also displayed in a form of one answer guide corresponding to one question guide. In one example, to facilitate a user's visual review of answers, the answer directions in the verification module may include specific answer content, i.e., the answers are displayed directly under their corresponding question directions. In another example, in order to provide a better browsing experience for the user in the case of more answer content, the answer guide in the verification module may also include a link, and the user may click on the link to trigger the Web interface to display an answer content interface corresponding to the link.

As shown in fig. 4, the verification module may specifically show the following:

question guideline 1 how do compilation verification?

Answer guide 1.Compiling verification method guidance。

Question guideline 2. What reason the configuration is not validated?

Answer guideline 2.Tag and authority validation principle。

In one example, the program after the rights are configured according to the rights configuration scheme is compiled and verified through the compilation verification method guidance in answer guide 1.

It will be appreciated that the answer directions in this embodiment include links. As shown in FIG. 4, for example, the user may click on answer guide 1 "in the verification module"Compiling verification method guidanceAnd triggering the Web interface to display an answer content interface corresponding to the link of the answer guide 1. The answer content interface may display how to verify the content that the configuration takes effect after configuring the SELinux security policy file. For example, it is possible to display how to determine a compiled file, a compiled image, and how to brush the contents of the like according to the addition path.

Optionally, in a possible implementation manner, the user configures the program corresponding to the program in the SELinux security policy file according to the permission configuration schemeWhen the rights are, there may be cases where the configuration is not validated. This situation matches the question guideline 2 displayed by the verification module, at which point the user can click on answer guideline 2 "in the verification module" Tag and authority validation principleAnd triggering the Web interface to display an answer content interface corresponding to the link of the answer guide 2. The answer content interface can display specific contents of the tag and the validation principle of the authority. For example, after the SELinux security policy file is configured, details of how the authority is compiled and loaded into effect, intermediates of the whole process, and the like are displayed, so that a user can judge in which step the authority is in effect, and the user can conveniently adjust the configured program.

In the verification module provided by the embodiment of the application, various compiling and verifying methods of the program are displayed through the verification module, and the compiling and verifying methods can be used for compiling and verifying the program after the SELinux security policy file is configured, so that whether the configuration is effective or not is verified, and the program can be executed according to expectations. And the verification module also displays the validation principle, and when the configuration is not validated, the user can be guided to find out the reason that the configuration is not validated based on the validation principle, so that the program is adjusted, and the program can be finally executed according to expectations.

The knowledge presentation module included in the Web interface is described below. Illustratively, the knowledge presentation module presents the relevant knowledge of SELinux, which includes signature relevant knowledge (such as APK signature problem), SELinux basic knowledge, security knowledge, and the like. A user can learn the security knowledge of the SELinux technology and the information security field through the content displayed by the knowledge display module, and know more related content of the SELinux and various reasons that the program is not executed according to expectations.

In order to facilitate the user to learn more related content of SELinux quickly and systematically, and for various reasons that the program is not executed as expected, the content displayed by the knowledge display module is also displayed in a form that one question guide corresponds to one answer guide. In one example, to facilitate a user's visual review of answers, the answer directions in the knowledge presentation module may include specific answer content, i.e., the answers are displayed directly under their corresponding question directions. In another example, in order to provide a better browsing experience for the user in the case of more answer content, the answer guide in the knowledge presentation module may also include a link, and the user may click on the link to trigger the Web interface to display an answer content interface corresponding to the link.

As shown in fig. 4, the knowledge presentation module may specifically present the following:

question guideline 1.Apk label question?

Answer guide 1.SELinux apk tags detailed。

Problem guideline 2.Selinux underlying knowledge

Answer guideline 2.SELinux basic knowledge

Problem guideline 3.OS Security team

Answer guide 3.OS Security team

Illustratively, the SELinux apk tag details a process that includes determining an application tag from an application signature and a package name. It should be understood that each application program is installed and needs to have its own tag, and the whole process of determining the application tag according to the application signature and package name after the application program is installed is described in detail herein, so that the user can learn conveniently.

The SELinux basic knowledge comprises the principles of SELinux, problem analysis, instruction adding and the like. The OS security team includes team introduction, team knowledge base, etc.

Illustratively, the user may click on "selinux basic knowledge" of answer guide 2 in the knowledge presentation module, and trigger the Web interface to display an answer content interface corresponding to the link of answer guide 2. The answer content interface may display the principles of SELinux, question analysis, add instruction, etc.

In the knowledge display module provided by the embodiment of the application, related knowledge of SELinux is displayed, and a user can learn the security knowledge of the SELinux technology and the information security field through the content displayed by the knowledge display module, so as to know various reasons that a program is not executed according to expectations, and the like. If the problem that the program is not executed according to the expectations is not solved by the reason confirmation module, the analysis module and the verification module, the problem can be solved after learning the content of the knowledge display module.

The front-end interface displayed in the electronic device according to the embodiment of the present application is described in detail, and in the following embodiments of the present application, the electronic device and the server are taken as examples, and the method for configuring the SELinux security policy provided in the embodiment of the present application is specifically described in conjunction with the accompanying drawings and application scenarios.

Referring to fig. 8, fig. 8 is a flowchart of a method for configuring SELinux security policy according to an embodiment of the present application. The method comprises the following steps:

s101, acquiring request information sent by the electronic equipment.

The request information includes the reason type corresponding to the reason that the program did not execute as expected and AVC alert information of the program.

Illustratively, the server obtains the reason type sent by the electronic device and AVC alert information for the program. Specifically, when the program is found to be not executed as expected, in a cause confirmation module of a front-end interface of the electronic device, a problem possibly occurring in the program is queried, namely, a cause type causing the program to be executed as expected is queried in the cause confirmation module.

And acquiring the AVC alarm information of the program according to the method for acquiring the AVC alarm information displayed by the reason confirmation module. For example, the method for obtaining the AVC alert information includes a storage path of the generated AVC alert information, and the user may extract the AVC alert information of the program according to the storage path.

Illustratively, the request information (i.e., the reason type and AVC alert information) determined by the reason confirmation module is input to the analysis module, which transmits the input request information to the server. Specifically, in order to facilitate the user to quickly input the request information, different input boxes and/or selection boxes are provided in the analysis module, and the user can input the request information in the corresponding input boxes and/or selection boxes according to the prompt. A submit button can be displayed in the analysis module, and after the user inputs the request information, the user can click on the submit button to trigger a submit instruction, and the electronic equipment sends the request information to the server according to the submit instruction.

It can be understood that the server analyzes based on the request information sent by the electronic device, so that the information sent by the electronic device to the server is more comprehensive, and the analysis result of the server is more accurate. Thus, in one possible implementation, the request information may further include one or more of platform information, chip component information, system component information, attribute information, tag information, and path information on the basis of AVC alert information including a cause type and a program.

The platform information refers to a platform used by a development program, the chip component information refers to a chip component version used by the development program, the system component information refers to a system component version used by the development program, the attribute information can comprise read attributes and/or write attributes of files, the tag information can comprise tag names, the path information can comprise file/executable file paths and the like.

S102, analyzing the request information to obtain an analysis result.

Illustratively, the AVC alert information is parsed, thereby extracting preset keywords in the AVC alert information. The preset key includes at least one of name, scontext, tcontext, class and permas.

For example, each word symbol in the AVC alert information is sequentially read, and whether the current word symbol belongs to a preset keyword, operator, delimiter, identifier, etc. is queried. And if the current word symbol belongs to the preset keyword, marking the current word symbol or extracting the current word symbol.

The name of the accessed subject can be determined by presetting a key name; the main body label can be determined by presetting a keyword scontext; the object label can be determined by presetting a keyword tcontext; the type of the object can be determined by presetting a keyword class; the rights type can be determined by presetting a key perms.

It should be appreciated that in the SELinux system, all subjects (e.g., processes) and guests (e.g., resources) have a tag. Wherein the subject label represents a label of the process and the object label represents a label of the resource to be accessed.

Illustratively, according to the reason type in the request information, determining the authority statement to be added corresponding to the reason type. For example, the corresponding relation between different reason types and the corresponding rights statement to be added is pre-established and stored in a database. And after receiving the request information, searching a right statement to be added, which is matched with the reason type in the request information, in a database.

For example, when the reason type is the newly added general file type, the corresponding permission statement to be added may be:

your_file.te：

type you_file_label, file_type, system_file_type; defining executable file tags

file_contexts：

you_file u object r you_file_label s0// labelling

This is merely an exemplary illustration and is not limiting in this regard.

Optionally, in one possible implementation, the validity of the AVC alert information may be determined first after step S101. For example, it is detected whether AVC alert information contains a field AVC, denied, name, ino, scontext, tcontext, class, perms or not. If the information is included, the AVC alarm information is proved to be legal, and the meaning of each field is further analyzed. And if the information is not contained, proving that the AVC alarm information is illegal. At this time, the server generates failure prompt information and sends the failure prompt information to the electronic device. After receiving the failure prompt information, the electronic equipment displays the failure prompt information in an analysis module for a user to check.

And analyzing each field in the AVC alarm information, on one hand, judging whether the AVC alarm information is legal or not, if not, directly returning a result, and not carrying out subsequent analysis, thereby saving time. On the other hand, the subject label and the object label corresponding to the program can be determined according to the extracted preset keywords, so that a guarantee is provided for the subsequent generation of the permission configuration scheme.

S103, generating a permission configuration scheme of the program according to the analysis result.

The authority configuration scheme is used for configuring a SELinux security policy file of the program, and comprises an authority statement to be added and an adding position.

According to the subject tag and the object tag determined in S102, a path defining the subject tag and the object tag is searched in a preset data table, that is, a position defining the subject tag and the object tag (that is, a position defining the subject tag and the object tag when the subject tag and the object tag are defined) is searched, and the path (or the position) is an adding position.

Wherein the data table is pre-stored in the database. The database is a "warehouse" for storing data, and in the embodiment of the present application, codes corresponding to pre-developed programs are stored in the database. The code stored in the database may be updated periodically, for example, by creating a timed task, and periodically downloading code corresponding to each program from the company's code bins.

At the same time, SELinux security policy files are also extracted from these codes periodically. And analyzing the attribute and type fields in the SELinux security policy file to obtain a path where the definition is located (namely an adding position in the authority configuration scheme), and storing the attribute and type fields and the corresponding path association where the definition is located in a data table.

In one possible implementation, when the attribute and type fields and the corresponding paths of the definition are stored, the code-related platform information, the chip component information, the system component information, and the like may also be stored in association. Or, different data tables are established in advance according to different platform information, chip component information, system component information and the like, and the attribute field, the type field and the corresponding definition position path are stored in the adaptive data table, so that the subsequent rapid searching of the definition position path according to the platform information, the chip component information, the system component information and the like is facilitated.

Illustratively, when actually looking up the addition location, attribute and type are input in the data table, output: the path is defined. It is generally understood that the input of the subject label and the object label and the output define the path along which the subject label and the object label are located.

And determining the authority statement to be added and the adding position, and obtaining the authority configuration scheme corresponding to the program. The server sends the rights configuration scheme to the electronic device. And after the electronic equipment receives the permission configuration scheme sent by the server, the permission configuration scheme is displayed in the analysis module. The user can add the rights statement to be added to the SELinux security policy file according to the addition position in the rights configuration scheme, so that the program can execute as expected.

In the implementation mode, the reason type and the AVC alarm information are analyzed, and a program authority configuration scheme is generated according to the analysis result. On the one hand, because the AVC alarm information is the most accurate in various SELinux authority detection methods, the automatic analysis is carried out based on the AVC alarm information, and the SELinux authority problem can be accurately reflected, so that the authority configuration scheme obtained after the analysis of the AVC alarm information is more accurate, and the safety condition caused by the analysis error can be effectively avoided. On the other hand, compared with the related art, the application comprises the addition position in the generated authority configuration scheme, so that a user cannot blindly configure the SELinux security policy file of the program, the user is facilitated to conveniently and efficiently configure the SELinux security policy file of the program, the configuration cost is reduced, the manpower is saved, and the security of the development software is improved.

Optionally, in some possible implementations, when specific information included in the request information is different, the correspondingly generated permission configuration schemes are also different. For example, if the request information has no AVC alarm information and only tag information, the generated permission configuration scheme is: only labeling is directed. For another example, only AVC alarm information is included in the request information, and no tag information is included, the generated permission configuration scheme is as follows: default already tagged, checking alarm validity, default (default) tag, alarm and reason type mismatch issues, etc. For another example, if AVC alarm information and tag information are included in the request information, the generated permission configuration scheme is: labeling and configuring rights. For another example, if the request information has no AVC alert information and no tag information, a failure hint information is generated: is illegal. This is merely illustrative and is not limiting.

Referring to fig. 9, fig. 9 is a flowchart illustrating a method for configuring SELinux security policy according to an exemplary embodiment of the present application. As shown in fig. 9, the method may include:

s201, acquiring request information, wherein the request information comprises AVC alarm information and reason type.

S202, judging whether the AVC alarm information is legal or not.

For the description of step S201 and step S202 in this embodiment, reference may be made to the description in step S101, which is not repeated here.

If the result is that the AVC alert information is illegal, step S203 is executed. If the judgment result is that the AVC alarm information is legal, step S204 is executed.

S203, returning failure prompt information.

S204, judging which type the reason type belongs to.

S205, belonging to the newly added process type.

S206, belonging to the newly added file type.

S207, belonging to the new authority type of the known host and guest.

Illustratively, according to the reason type in the request information, determining whether the reason type is an added process type, an added file type, an added authority type of a known host or an unlisted added attribute type. In one possible implementation, the new added attribute type may also be a subdivision domain that belongs to the new added file type. Such as the newly added file type in turn includes the newly added virtual file type, the newly added general file type, and the newly added attribute type. This is merely illustrative and is not limiting.

In the implementation mode, whether the AVC alarm information is legal or not is judged, if the AVC alarm information is illegal, failure prompt information is directly returned, subsequent analysis is not carried out, and time is saved. If the AVC alarm information is legal, the approximate range is determined according to the reason type, and the follow-up subdivision of the type according to the currently determined approximate range is facilitated, so that the speed of generating the permission configuration scheme is improved.

Referring to fig. 10, fig. 10 is a flowchart illustrating another method for configuring SELinux security policy according to an exemplary embodiment of the present application. It should be appreciated that different types of causes are determined and the subsequent process flows are different. When the reason type is the new authority type of the known host and client, the processing flow is as follows:

s301, determining a path where definition is located.

Illustratively, the paths of the defined subject labels and the object labels are searched in a preset data table, that is, the positions of the defined subject labels and the object labels are searched, for example, public, private, vendor. Wherein, vendor is private to the chip component, private to the system component, public. This is reflected in the compilation process, the chip component compiles vendor and public, and the system component compiles private and public.

S302, judging whether to cross-component access.

Illustratively, it is determined whether a path is a cross-component access between vendor and private based on which path is defined.

S303, determining a first adding method.

If the access is not the cross-component access between the vendor and the private, a first adding method is determined. The first adding method comprises the following steps: add an allow statement to the private/scontext.te of the self-grinding bin where the scontext is located (if attribute, getprop/setprop is used). According to the first adding method, the authority statement to be added can be obtained.

S304, determining a second adding method.

And if the components are accessed between the vendor and the private, determining a second adding method. The second adding method comprises the following steps: the attribute tag_attr is added to public/attribute of the self-grinding bin where the private tag is located, and the tag definition is added to the tag_attr. The context.te of the self-lapping bin where context defined by vendor is located adds an allow statement for attr (if attribute, getprop/setprop is used). According to the second adding method, the authority statement to be added can be obtained.

S305, judging whether the architecture is treble architecture.

Illustratively, whether the architecture is treble is determined according to the platform information in the request information.

S306, attribute needs to be added to the system component version corresponding to the chip component.

S307, generating a permission configuration scheme.

If the decision is a treble architecture, the attribute needs to be added to the system component version corresponding to the chip component. If the join path is not in the treble architecture, determining whether the join path is in the base co-bin according to the platform information in the request information, namely considering whether the join path is added to the co-bin position.

In popular terms, under the condition that the reason type is the new permission type of the known host and guest, if the access is non-cross-component access, the adding path is determined to be a self-grinding bin; if the access is cross-component access, defining an attribute as a bridge in public, adding access rights in a self-grinding bin of a vendor, and then performing treble architecture adaptation. During this time, it is also necessary to consider whether rights are added to the common bin location depending on whether the common platform is taking into account. And after the information is determined, generating a permission configuration scheme according to the permission statement to be added and the addition position, and sending the permission configuration scheme to the electronic equipment, wherein the electronic equipment is displayed in an analysis module of the Web interface.

In the implementation mode, when the reason type is the new permission type of the known host and client, the corresponding permission configuration scheme can be quickly generated by the mode, so that a user can efficiently and conveniently configure the SELinux security policy file of the program.

Referring to fig. 11, fig. 11 is a flowchart illustrating a method for configuring a SELinux security policy according to another exemplary embodiment of the present application. It should be appreciated that different types of causes are determined and the subsequent process flows are different. When the reason type is the newly added process type, the processing flow is as follows:

s401, acquiring path information and label information in the request information.

Illustratively, the path information may include a file/executable file path and the tag information may include a tag name.

S402, determining whether the new process is a system process or a vendor process.

Whether the system process or the vendor process is judged according to the file/executable file path, and then the you_service. Te defining the label and the file_contexts position of the label are determined.

S403, judging whether the process labels are multiplexed or not.

Judging whether the process label is a multiplexing label according to the label information, wherein the multiplexing label is a reused label.

S404, processing by adopting processing logic corresponding to the new permission type of the known host and client.

If the process tag is a multiplexing tag, processing is performed by adopting processing logic corresponding to the new authority type of the known host and guest, that is, processing is performed by adopting a mode in the embodiment corresponding to fig. 10.

S405, judging whether to serve the system process.

S406, adopting system process label processing.

S407, adopting a vendor process label to process.

Illustratively, if the process tag is not a multiplex tag, a determination is made as to whether the newly added process service is a system process service. If the newly added process service is a system process service, the system process label processing is adopted. And if the newly added process service is not the system process service, adopting the vendor process label to process. And then adopting processing logic corresponding to the new permission type of the known host and client to process.

In one example, assume that the input executable file path is: you_service_bin, process label is: the right_service, the generated right statement to be added is:

file_contexts:

you_service_bin u object r you_service_exec s0// labelling

If the process label is not the multiplexing label, the following first operation is performed:

If the system process service is provided, the authority statement to be added is:

your_service.te

type you_service, domain; process tag for/(and/or definition)

type you_service_exec, exec_type, file_type, system_file_type; defining executable file tags

typeattribute your _ service coredomain; tag class is added to/from a tag

init daemon domain (you service)// domain conversion

If the service is a vendor process service, the authority statement to be added is:

your_service.te

type you_service, domain; process tag for/(and/or definition)

type you_service_exec, exec_type, file_type, vendor_file_type; defining executable file tags

init daemon domain (you service)// domain conversion

If the process label is a multiplex label, the first operation is not performed.

In the implementation mode, when the reason type is the newly added process type, the authority statement to be added can be quickly generated by the mode, and a guarantee is provided for finally generating the authority configuration scheme, so that a subsequent user can efficiently and conveniently configure the SELinux security policy file of the program.

It should be appreciated that different types of causes are determined and the subsequent process flows are different. When the reason type is the newly added file type, determining the adding authority and the adding position according to the path information and the label information in the request information, and then determining which type of the newly added file type is the reason type. Such as an added virtual file type, an added general file type, an added attribute type, etc.

Optionally, in one possible implementation manner, when the reason type is the newly added virtual file type, the partition is first determined according to the file path: dev, sys, proc; if the file path is your device, determining the rights statement to be added according to the following mode:

partition name +fs_you_device.te:

type partition name + _you_device, fs_type, sysfs_type, partition name + fs_type// File tag definition

And generating the permission statement to be added in different modes according to different partition types.

If the partition is/sys partition, the authority statement to be added is:

genfs_contexts:

genfscon sysfs/you_device u: object_r: sysfs_you_device: s0// file tagging

If the partition is the/proc partition, the authority statement to be added is:

genfs_contexts:

genfscon procfs/you_device u: object_r: procfs_you_device s0// file tagging

If the partition is the// dev partition, the authority statement to be added is:

file_contexts:

labeling of/dev/you_deivce u: object r: devfs_you_device: s0// file

Optionally, in one possible implementation, when the reason type is an added general file type, the file path is assumed to be: you_file, tag is: the generated right statement to be added is:

your_file.te：

type you_file_label, file_type, system_file_type; (if vendor, vendor_file_type)

file_contexts：

you_file u object r you_file_label s0// labelling

Optionally, in one possible implementation, when the reason type is the newly added attribute type, determining which attribute is according to the authority type, for example, system_internal_prop only read and written in the system component; and then according to the label information in the request information, generating rights statement to be added as follows:

property.te：

system_internal_prop (you_prop)// define attribute tags

property_contexts:

ro.you_prop. U: object_r: you_prop: s0// attribute tagging

In the implementation mode, when the reason type is the newly added file type, the authority statement to be added can be quickly generated by the mode, and a guarantee is provided for finally generating the authority configuration scheme, so that a subsequent user can efficiently and conveniently configure the SELinux security policy file of the program.

Examples of the method for configuring SELinux security policies provided by the embodiments of the present application are described in detail above. It will be appreciated that the electronic device, in order to achieve the above-described functions, includes corresponding hardware and/or software modules that perform the respective functions. Those of skill in the art will readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality using different approaches for each particular application in conjunction with the embodiments, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The embodiment of the application can divide the functional modules of the electronic device according to the method example, for example, the functional modules can be divided into the functional modules corresponding to each function, for example, a reason confirming module, an analyzing module, a verifying module, a knowledge displaying module and the like, and two or more functions can be integrated in one module. The integrated modules may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be implemented in actual implementation.

It should be noted that, all relevant contents of each step related to the above method embodiment may be cited to the functional description of the corresponding functional module, which is not described herein.

In case an integrated unit is employed, the electronic device may further comprise a processing module, a storage module and a communication module. The processing module can be used for controlling and managing the actions of the electronic equipment. The memory module may be used to support the electronic device to execute stored program code, data, etc. And the communication module can be used for supporting the communication between the electronic device and other devices.

Wherein the processing module may be a processor or a controller. Which may implement or perform the various exemplary logic blocks, modules and circuits described in connection with this disclosure. A processor may also be a combination that performs computing functions, e.g., including one or more microprocessors, digital signal processing (digital signal processing, DSP) and microprocessor combinations, and the like. The memory module may be a memory. The communication module can be a radio frequency circuit, a Bluetooth chip, a WiFi chip and other equipment which interact with other electronic equipment.

The embodiment of the application also provides a computer readable storage medium, in which a computer program is stored, which when executed by a processor, causes the processor to execute the method for configuring SELinux security policies according to any of the embodiments above.

The embodiment of the present application further provides a computer program product, which when run on a computer, causes the computer to perform the above-mentioned related steps to implement the method for configuring SELinux security policies in the above-mentioned embodiments.

The embodiment of the application also provides a server which is used for realizing the method for configuring the SELinux security policy in the embodiment.

The embodiment of the application also provides a chip. Referring to fig. 12, fig. 12 is a schematic structural diagram of a chip according to an embodiment of the application. The chip shown in fig. 12 may be a general-purpose processor or a special-purpose processor. The chip includes a processor 510. The processor 510 is configured to execute the method for configuring SELinux security policy according to any of the foregoing embodiments.

Optionally, the chip further comprises a transceiver 520, and the transceiver 520 is configured to receive control of the processor and is configured to support the communication device to perform the foregoing technical solution.

Optionally, the chip shown in fig. 12 may further include: a storage medium 530.

It should be noted that the chip shown in fig. 12 may be implemented using the following circuits or devices: one or more field programmable gate arrays (field programmable gate array, FPGA), programmable logic devices (programmable logic device, PLD), controllers, state machines, gate logic, discrete hardware components, any other suitable circuit or combination of circuits capable of performing the various functions described throughout this application.

The electronic device, the computer readable storage medium, the computer program product or the chip provided in this embodiment are used to execute the corresponding method provided above, so that the beneficial effects thereof can be referred to the beneficial effects in the corresponding method provided above, and will not be described herein.

It will be appreciated by those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts shown as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the methods of 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 (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the application is subject to the protection scope of the claims.

Claims

1. A method of configuring SELinux security policies, comprising:

acquiring request information, wherein the request information comprises a reason type corresponding to a reason that a program is not executed according to expectations and AVC alarm information of the program;

analyzing the request information to obtain an analysis result;

generating a permission configuration scheme of the program according to the analysis result, wherein the permission configuration scheme is used for configuring a SELinux security policy file of the program, and comprises permission sentences to be added and adding positions.

2. The method of claim 1, wherein the analysis result includes a subject tag and an object tag corresponding to the program, and the authority statement to be added, and the analyzing the request information to obtain the analysis result includes:

Extracting preset keywords in the AVC alarm information;

determining a subject label and an object label corresponding to the program according to the preset keywords;

and searching the authority statement to be added corresponding to the reason type in a database.

3. The method of claim 1, wherein the generating a rights configuration scheme for the program according to the analysis result comprises:

searching an adding position matched with the subject label and the object label corresponding to the program in a preset data table;

and generating the permission configuration scheme according to the permission statement to be added and the addition position.

4. The method of claim 2, wherein the preset key comprises at least one of name, scontext, tcontext, class and permas.

5. The method of any one of claims 1 to 4, wherein the request information further includes at least one of platform information, chip component information, system component information, attribute information, tag information, and path information.

6. A system for configuring SELinux security policies, comprising: the reason confirming module and the analyzing module;

The reason confirming module is used for displaying SELinux guide information and a method for acquiring AVC alarm information, wherein the SELinux guide information is used for determining a reason type corresponding to a reason that a program is not executed according to expectations, and the method for acquiring the AVC alarm information is used for acquiring the AVC alarm information of the program;

the analysis module is used for determining and displaying a permission configuration scheme of the program according to AVC alarm information and the reason type of the program, wherein the permission configuration scheme is used for configuring a SELinux security policy file of the program, and comprises permission sentences to be added and adding positions.

7. The system of claim 6, wherein the analysis module is further configured to,

extracting preset keywords in the AVC alarm information;

searching the authority statement to be added corresponding to the reason type in a database;

8. The system of claim 6 or 7, wherein the system further comprises a verification module;

the verification module is used for displaying various compiling and verifying methods, and the compiling and verifying methods are used for compiling and verifying programs after the SELinux security policy file is configured.

9. The system of any one of claims 6 to 8, wherein the system further comprises a knowledge presentation module;

the knowledge display module is used for displaying related knowledge of SELinux, wherein the related knowledge comprises basic knowledge and safety knowledge of SELinux.

10. An electronic device, comprising: one or more processors; one or more memories; the memory stores one or more programs that, when executed by the processor, cause the electronic device to perform the method of any of claims 1-5.

11. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program which, when executed by a processor, causes the processor to perform the method of any of claims 1 to 5.