Interface authority management method and device, equipment, storage medium and program product

Abstract

The invention provides an interface permission management method and device, equipment, a storage medium and a program product, and the method comprises the steps: obtaining a configuration file of a target application, the configuration file comprises an interface calling permission of the target application and a plurality of interfaces expected to be called by the target application under the interface calling permission, the interface calling permission of the target application is an interface type allowed to be used by the target application authorized by the operating system; and based on a plurality of interfaces expected to be called by the target application under the interface calling permission, creating an interface white list of the target application in a kernel of the operating system. By allocating the specific interface calling permission to the target application, the operating system can ensure that the application can only access and operate clearly allowed resources, and the refined permission control is beneficial to preventing unauthorized access and data leakage, so that the security of the operating system is improved.

Description

Technical Field

[0001] The present disclosure relates to the field of computer processing technology, and in particular to an interface authority management method, device, equipment, storage medium and program product. Background Art

[0002] Usually, the operating system provides a series of system calls (also called interfaces) that serve as bridges to enable applications to safely and efficiently access and use the relevant functions and resources provided by the kernel. However, if applications arbitrarily use multiple interfaces provided by the kernel to access and use the relevant functions and resources provided by the kernel, it may cause security problems to the operating system. Summary of the invention

[0003] The present disclosure provides an interface authority management method, apparatus, device, storage medium and program product, which can improve the security of an operating system.

[0004] In a first aspect, the present disclosure provides an interface permission management method, the method comprising: obtaining a configuration file of a target application, the configuration file comprising an interface calling permission of the target application, and a plurality of interfaces that the target application expects to call under the interface calling permission, the interface calling permission of the target application being the type of interface that the operating system authorizes the target application to use; based on the plurality of interfaces that the target application expects to call under the interface calling permission, creating an interface whitelist of the target application in the kernel of the operating system.

[0005] In some embodiments, based on multiple interfaces that the target application expects to call under interface calling permissions, an interface whitelist of the target application is created in the kernel of the operating system, including: verifying the interface calling permissions of the target application with the interface type corresponding to the target application in the authorization file of the operating system, the authorization file including multiple interface types and multiple applications corresponding to each of the multiple interface types; if the verification passes, creating an interface whitelist of the target application in the kernel, the interfaces in the interface whitelist being the same as the interfaces that the target application expects to call under the interface calling permissions.

[0006] In some embodiments, multiple interface types include at least one of a public type, a protected type, and a private type, wherein the public type is used to indicate an interface type that is disclosed to multiple external applications running on the operating system, the protected type is used to indicate an interface type that is disclosed to some external applications, and the private type is used to indicate an interface type that cannot be used by external applications, and the multiple applications include external applications and internal applications of the operating system; the interface call permissions of the multiple applications include at least one of a public permission, a protected permission, and a private permission, wherein the public permission is used to indicate that the application is authorized to call an interface of a public type, the protected permission is used to indicate that the application is authorized to call an interface of a protected type, and the private permission is used to indicate that the application is authorized to call an interface of a private type.

[0007] In some embodiments, the authorization file includes interface information of multiple interfaces included in each of multiple interface types; the method also includes: sending the authorization file to the target application so that the target application configures the multiple interfaces that the target application expects to call under the interface call permission based on the interface type corresponding to the target application and the interface information of the multiple interfaces included in the interface type.

[0008] In some embodiments, the authorization file includes interface information of multiple interfaces included in each of multiple interface types; when the interface calling permission of the target application is protection permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the protection permission, and multiple interfaces included in the public type; when the interface calling permission of the target application is private permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the private permission, and multiple interfaces included in the public type.

[0009] In some embodiments, the multiple interface types are obtained by classifying multiple interfaces in the operating system according to the security levels disclosed by the interfaces.

[0010] In a second aspect, the present disclosure provides an interface permission management device, which includes: an acquisition module, used to acquire a configuration file of a target application, the configuration file including the interface calling permission of the target application, and multiple interfaces that the target application expects to call under the interface calling permission, the interface calling permission of the target application is the interface type authorized by the operating system for the target application to use; a creation module, used to create an interface whitelist of the target application in the kernel of the operating system based on the multiple interfaces that the target application expects to call under the interface calling permission.

[0011] In some embodiments, the creation module is also used to: verify the interface call permission of the target application with the interface type corresponding to the target application in the authorization file of the operating system, the authorization file includes multiple interface types, and multiple applications corresponding to each of the multiple interface types; if the verification is passed, create an interface whitelist of the target application in the kernel, and the interfaces in the interface whitelist are the same as the interfaces that the target application expects to call under the interface call permission.

[0012] In some embodiments, multiple interface types include at least one of a public type, a protected type, and a private type, wherein the public type is used to indicate an interface type that is disclosed to multiple external applications running on the operating system, the protected type is used to indicate an interface type that is disclosed to some external applications, and the private type is used to indicate an interface type that cannot be used by external applications, and the multiple applications include external applications and internal applications of the operating system; the interface call permissions of the multiple applications include at least one of a public permission, a protected permission, and a private permission, wherein the public permission is used to indicate that the application is authorized to call an interface of a public type, the protected permission is used to indicate that the application is authorized to call an interface of a protected type, and the private permission is used to indicate that the application is authorized to call an interface of a private type.

[0013] In some embodiments, the authorization file includes interface information of multiple interfaces included in each of multiple interface types; the device also includes: a sending module for sending the authorization file to the target application, so that the target application configures the multiple interfaces that the target application expects to call under the interface call permission based on the interface type corresponding to the target application and the interface information of the multiple interfaces included in the interface type.

[0014] In some embodiments, the authorization file includes interface information of multiple interfaces included in each of multiple interface types; when the interface calling permission of the target application is protection permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the protection permission, and multiple interfaces included in the public type; when the interface calling permission of the target application is private permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the private permission, and multiple interfaces included in the public type.

[0015] In some embodiments, the multiple interface types are obtained by classifying multiple interfaces in the operating system according to the security levels disclosed by the interfaces.

[0016] In a third aspect, the present disclosure provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor implements the steps in the above method when executing the program.

[0017] In a fourth aspect, the present disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps in the above method when executed.

[0018] In a fifth aspect, the present disclosure provides a computer program product, comprising a non-transitory computer-readable storage medium storing a computer program, wherein the computer program implements the steps in the above method when executed.

[0019] Compared with the prior art, the technical solution provided by the present disclosure has the following beneficial effects:

[0020] In the disclosed embodiment, the interface call permission of the target application and the multiple interfaces that the target application expects to call under the interface call permission are obtained, and then based on the multiple interfaces that the target application expects to call under the interface call permission, the interface whitelist of the target application is created in the kernel of the operating system. Since the interface call permission of the target application is the type of interface that the operating system authorizes the target application to use, by assigning specific interface call permissions to the target application, the operating system can ensure that the application can only access and operate resources that are explicitly allowed. This refined permission control helps prevent unauthorized access and data leakage, thereby improving the security of the operating system. Further, through the whitelist mechanism, the operating system can reject interface call requests that do not meet the conditions, thereby reducing unnecessary resource consumption and helping to improve the overall performance and response rate of the operating system. In addition, since the interfaces in the whitelist are pre-authorized by the operating system, the operating system can process these interface call requests faster, thereby improving the efficiency of interface calls.

[0021] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0023] Figure 1 This is a schematic diagram of an implementation flow of the interface authority management method provided by the embodiment of the present disclosure;

[0024] Figure 2 is a schematic diagram of the interface number provided by the embodiment of the present disclosure;

[0025] Figure 3 is a schematic diagram of an application calling interface provided by an embodiment of the present disclosure;

[0026] Figure 4 This is a schematic diagram of the implementation process of creating an interface whitelist provided by an embodiment of the present disclosure;

[0027] Figure 5 It is a schematic diagram of the composition structure of an interface authority management device provided by an embodiment of the present disclosure;

[0028] Figure 6 It is a hardware entity schematic diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

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

[0030] Before explaining in detail the interface permission management method provided by the embodiment of the present disclosure, the application scenario of the embodiment of the present disclosure is first introduced.

[0031] The operating system uses multiple interfaces to ensure that applications can access and use the relevant functions and resources provided by the kernel in a safe and efficient manner. In other words, the interface is the key channel for the interaction between the application and the kernel of the operating system. Through the call of these interfaces, the application can request to perform various low-level operations, such as file reading and writing, process management, memory allocation and release, etc. However, if the application uses the interface provided by the kernel at will, it may cause security problems to the operating system. Therefore, the general operating system will provide an interface permission management method to improve the security of the operating system.

[0032] At present, some operating systems, such as the Linux operating system, enable interface filters by providing a secure computing mode (SECCOMP) mechanism, so that the application itself determines the interface to be used, and then adds the interface to be used to the application configuration file. Among them, the SECCOMP mechanism allows user-mode applications to filter and restrict when calling interfaces. Through the SECCOMP mechanism, the operating system administrator or developer can define a filter to specify the interfaces that are allowed or prohibited to be called by the application through the filter. Other operating systems, such as the QNX operating system, add some interfaces that require security control to the operating system's capability mechanism, and restrict application calls to interfaces through the capability configuration file. Moreover, the configuration needs to be controlled according to each interface. Among them, the capability mechanism is a permission management mechanism for managing and controlling access to operating system resources. This mechanism allows the operating system to manage resources and access control in a fine-grained and flexible manner. Capability can be understood as a key that gives the holder specific permissions to operate or access objects in the operating system.

[0033] However, the Linux operating system is an open source operating system. Therefore, all interfaces in the Linux operating system are open, and all applications can obtain the interface names defined by the operating system. However, for commercial closed-source operating systems, in order to ensure security, operating system developers will hide some interfaces and prevent the outside world from knowing these interface names. The interface protection mechanism of the Linux operating system cannot do this, which will cause security issues. In addition, the QNX operating system only controls the permissions of some interfaces through the capability mechanism. Other interfaces that are not controlled can still be called by applications at will, which still causes security issues.

[0034] Based on the above problems, an embodiment of the present disclosure provides an interface permission management method. By assigning specific interface call permissions to the target application, the operating system can ensure that the application can only access and operate resources that are explicitly permitted. This refined permission control helps prevent unauthorized access and data leakage, thereby improving the security of the operating system.

[0035] Figure 1 FIG. 1 is a flow chart of an implementation of the interface permission management method provided by the embodiment of the present disclosure. By way of example, the method may be executed by an application loader in an operating system. Figure 1 As shown, the method includes the following steps S101 to S102.

[0036] In step S101, a configuration file of a target application is obtained.

[0037] In some embodiments, the target application is an external application running on the operating system or an internal application of the operating system. Among them, external applications refer to applications written by third-party developers and installed on the device where the operating system is located. These applications are usually not system applications that come with the device, but are downloaded and installed by users according to their needs, such as social media applications, game applications, office software and other applications. Internal applications generally refer to applications that come with the operating system and are pre-installed on the device. These applications are part of the operating system and are used to provide basic services and functions, such as file managers, browsers, cameras, and photo albums. Whether they are external applications or internal applications, they all need to interact with the operating system through the interface of the operating system. Therefore, the application loader in the operating system can obtain the configuration file of the target application at the stage of loading the target application, and determine the interface that the target application can call based on the configuration file.

[0038] In some embodiments, the configuration file includes the interface calling permission of the target application and multiple interfaces that the target application expects to call under the interface calling permission. The interface calling permission of the target application is the interface type authorized by the operating system to be used by the target application.

[0039] In the disclosed embodiment, the operating system pre-authorizes which types of interfaces an application can use. In this way, the operating system can send an authorization file to the application so that the application obtains its own interface calling permissions, and then configures the set of interfaces that it expects to call under the corresponding interface calling permissions in its own capability configuration file.

[0040] In some embodiments, the authorization file of the operating system includes multiple interface types and multiple applications corresponding to each of the multiple interface types.

[0041] In some embodiments, the multiple interface types are obtained by classifying multiple interfaces in the operating system according to the security levels disclosed by the interfaces.

[0042] Understandably, in the design and development of operating systems, the classification of interfaces is an important link, which helps to ensure the security, maintainability and scalability of the operating system. Classifying interfaces in the operating system according to security levels is a method of dividing interfaces according to the degree of risk they are exposed to the outside world. This classification method helps developers identify which interfaces require additional security protection and which interfaces can be relatively open. By classifying interfaces by security level, developers can implement security measures more specifically to ensure the overall security of the operating system. At the same time, this classification also helps to identify and resolve potential security risks during the development process.

[0043] For example, interfaces are classified according to security levels, and the resulting multiple interface types may include: public type, restricted type, internal type, and sensitive type. Among them, public type interfaces are open to all applications. Restricted type interfaces may only be open to specific applications, or only under certain conditions. For example, some interfaces may only be accessible in a specific network environment or after authentication. Internal type interfaces are mainly used for communication between internal components of the operating system and are usually not open to external applications. Sensitive type interfaces are used to process sensitive data or perform sensitive operations, such as accessing user privacy information, performing system-level changes, etc. These interfaces usually require the highest level of security protection, including strong authentication, access control, data encryption, etc.

[0044] It can be understood that after classifying multiple interfaces, the operating system obtains multiple interface types, each of which includes multiple interfaces. The operating system then authorizes each application to use the interface type, and manages the permissions of the interface type through the capability mechanism, so that the operating system can configure the authorization file. After that, the operating system can send the authorization file to the application so that the application obtains its own interface call permission, and then configures the interface set that it expects to call under the corresponding interface call permission in its own capability configuration file.

[0045] Therefore, the authorization file may include multiple interface types and multiple interface call permissions, interface information of multiple interfaces included in each interface type in the multiple interface types, and multiple applications corresponding to each interface type. Among them, each interface type corresponds to an interface call permission. Interface information may include information such as interface name, interface description, interface address, request parameters, etc. The interface name is a unique identifier or name of the interface. The interface description is a brief description of the interface function, purpose, usage scenario, etc. The interface address is the Uniform Resource Locator (URL) or Internet Protocol (IP) address of the interface, and possible port number, used for network communication. Request parameters are a list of parameters that need to be provided when calling an interface, including parameter name, type, whether required, default value, description, etc.

[0046] In the disclosed embodiment, the operating system pre-classifies all interfaces according to the security level of interface disclosure, manages interface permissions for multiple interface types through capabilities, and configures interface call permissions for each application. In this way, the operating system can manage permissions for all interfaces based on the interface types that the operating system authorizes the application to use, solving the problem that the capability mechanism only manages some interfaces.

[0047] In some embodiments, multiple interface types include at least one of a public type, a protected type, and a private type, wherein the public type is used to indicate an interface type that is disclosed to multiple external applications for use, the protected type is used to indicate an interface type that is disclosed to some external applications for use, and the private type is used to indicate an interface type that cannot be used by external applications; the interface calling permissions of multiple applications include at least one of a public permission, a protected permission, and a private permission, wherein the public permission is used to indicate that the application is authorized to call an interface of a public type, the protected permission is used to indicate that the application is authorized to call an interface of a protected type, and the private permission is used to indicate that the application is authorized to call an interface of a private type.

[0048] It can be understood that the operating system can classify all interfaces into public type, protected type and private type according to the security level of the interface disclosure. The interfaces that are completely open to external applications for free selection by external applications are classified as public type, the interfaces that require operating system authorization to use are classified as protected type, and the interfaces that the operating system does not want the outside world to know are classified as private type.

[0049] It should be noted that the above description divides the interface types into three categories. In fact, the interface types are not limited to the above three categories, and the classification can be increased or decreased according to the actual situation. For example, some interfaces can be classified as authorized access types, and this type of interface may only be open to applications developed by specific manufacturers.

[0050] In some embodiments, the operating system may define each interface and obtain the interface number of each interface. Figure 2 is a schematic diagram of the interface number provided by the present disclosure. Figure 2 As shown, the high-order byte of the interface can be configured as the interface type number, and the low-order byte can be configured as the specific interface number. It can be understood that the high-order byte is used to distinguish different types of interfaces. After determining the interface type, the low-order byte is used to further distinguish different interfaces under the same interface type. Each interface has a unique interface number so that the operating system can correctly identify them. The above is just a division method. In fact, the division of high and low bits can be divided according to actual conditions.

[0051] For example, when the interface type includes a public type, a protected type and a private type, the interface type number can be defined as: the interface type number of the public type (SYSCALL_TYPE_PUBLIC) is 0, the interface type number of the protected type (SYSCALL_TYPE_PROTECT) is 1, and the interface type number of the private type (SYSCALL_TYPE_PRIVATE) is 2.

[0052] For example, the interface number can be any natural number within the range limited by the low bit. For example, if the low bit is defined as 16 bits, the interface number can range from 0 to 2^16-1=65535, which means that the operating system can support a maximum of 65535 different interfaces.

[0053] It is understandable that after classifying the interfaces, the operating system can manage the permissions of the interface types through capabilities, that is, one interface type corresponds to one interface calling permission. For example, when the interface types include public type, protected type and private type, the operating system can define interface calling permissions in the capabilities of the process, where the public type corresponds to the public permission (CAP-PUBLIC), that is, the public permission is used to indicate that the application is authorized to call the public type interface. The protected type corresponds to the protection permission (CAP_PROTECT), that is, the protection permission is used to indicate that the application is authorized to call the protected type interface. The private type corresponds to the private permission (CAP_PRIVATE), that is, the private permission is used to indicate that the application is authorized to call the private type interface.

[0054] In some embodiments, the operating system may send the authorization file to the target application so that the target application configures multiple interfaces that the target application expects to call under the interface call permission based on the interface type corresponding to the target application and the interface information of the multiple interfaces included in the interface type.

[0055] It is understandable that after the operating system classifies the interfaces and manages the permissions of the interface types through capabilities, the authorization file can be sent to the target application after the configuration is completed. In this way, the target application can determine the interface it expects to call from the multiple interfaces included in the corresponding interface type in the authorization file based on its own interface call permissions.

[0056] For example, each interface type in the authorization file includes multiple interfaces. If the interface calling permission of the target application is a public permission, the target application can determine the public interface that is expected to be called from the multiple public interfaces included in the public type to obtain an interface calling set.

[0057] For public types, if the target application is authorized by the operating system to use the public type interface, the target application needs the minimum permissions and executes the sandbox mechanism. The target application can configure the public interface set that it expects to call in its own capability profile. If the target application is not authorized by the operating system to use the public type interface, the target application is a common application and does not need to execute the sandbox mechanism. The target application does not need to configure the public interface set in the capability profile. In this way, the target application can call all public interfaces included in the public type.

[0058] For protection types, if the target application is authorized by the operating system to use interfaces of the protection type, the target application can configure the protection interface set it expects to call in its capability profile. If the target application is not authorized by the operating system to use interfaces of the protection type, the target application does not need to configure the protection interface set in the capability profile, so the target application cannot call all protection interfaces included in the protection type.

[0059] For private types, if the target application is authorized by the operating system to use the interface of the private type, the target application can configure the private interface set it expects to call in its own capability profile. If the target application is not authorized by the operating system to use the interface of the private type, the target application does not need to configure the private interface set in the capability profile, so the target application cannot call all the private interfaces included in the private type.

[0060] Figure 3 Schematic diagram of the application calling interface provided by the embodiment of the present disclosure. Figure 3 As shown in the figure, the operating system authorizes application capabilities in the kernel as follows: application 1 {capr = syscall_public}, application 2 {capr = syscall_protect}, application 3 {capr = syscall_private}, indicating that the operating system authorizes application 1 to use public interfaces, application 2 to use protected interfaces, and application 3 to use private interfaces. In this way, application 1 can configure the public interfaces that it expects to call in its own capability configuration file, such as ["sys_call_1", "sys_call_2", "sys_call_8"...], in fact, Figure 3 The application capability profile of application 1 also includes "sys_call_19" and "sys_call_67". Application 2 configures the protection interfaces that it expects to call in its own capability profile, such as ["sys_call_3", "sys_call_5", "sys_call_17" ...]. In fact, Figure 3 The application capability profile of application 2 also includes "sys_call_16" and "sys_call_23". Application 3 configures the private interfaces that it expects to call in its own capability profile, such as ["sys_call_4", "sys_call_6", "sys_call_9" ...]. In fact, Figure 3The application capability profile of application 3 also includes "sys_call_11" and "sys_call_22". In this way, application 1 can call the public interfaces ["sys_call_1", "sys_call_2", "sys_call_8", "sys_call_19", "sys_call_67"] in the public type according to the configuration, but cannot call the protected interfaces in the protected type and the private interfaces in the private type. Application 2 can call all public interfaces in the public type, call the protected interfaces ["sys_call_3", "sys_call_5", "sys_call_17", "sys_call_16", "sys_call_23"] in the protected type according to the configuration, but cannot call the private interfaces in the private type. Application 3 can call all public interfaces in the public type, cannot call the protected interfaces in the protected type, and call the private interfaces ["sys_call_4", "sys_call_6", "sys_call_9", "sys_call_11", "sys_call_22"] in the private type according to the configuration.

[0061] In step S102, based on a plurality of interfaces that the target application expects to call under the interface calling authority, an interface whitelist of the target application is created in the kernel of the operating system.

[0062] It can be understood that when the target application is loaded and executed by the application loader, during the stage of the target application being loaded, the application loader can obtain the configuration file of the target application to the kernel, and then create an interface whitelist of the target application in the kernel according to the multiple interfaces that the target application expects to call under the interface call permission, and bind it to the target application. In this way, the next time the target application requests to call a certain interface, the application loader can directly verify whether the target application can call the interface in the interface whitelist of the target application in the kernel, which can improve the operation efficiency.

[0063] For example, if the interface call permission of the target application is a protection permission, and the protection interfaces that the target application expects to call under the protection permission include interface 1, interface 2, and interface 3, then the application loader can write interface 1, interface 2, and interface 3 into the interface whitelist of the target application in the kernel, so that the next time the target application requests to call a certain interface, the application loader can directly search the interface whitelist of the target application in the kernel to see whether the interface exists, and determine whether the target interface is allowed to call the interface based on the search result. For example, if the target application requests to call interface 3, interface 3 is in the whitelist of the target application, so the application loader allows the target application to call interface 3, and the target application can call interface 3 to perform the corresponding operation. If the target application requests to call interface 4, interface 4 is not in the whitelist of the target application, so the application loader prohibits the target application from calling interface 4, and the target application cannot call application 4 to perform related operations.

[0064] In some embodiments, the implementation process of step S102 may be: verifying the interface call permission of the target application with the interface type corresponding to the target application in the authorization file of the operating system, the authorization file including multiple interface types, and multiple applications corresponding to each of the multiple interface types; if the verification is passed, creating an interface whitelist of the target application in the kernel, and the interfaces in the interface whitelist are the same as the interfaces that the target application expects to call under the interface call permission.

[0065] It is understandable that when the operating system runs the target application, it can also perform permission verification, that is, the application loader can read the configuration file of the target application into the kernel and match the data with the authorization file in the kernel. If it matches, the data of the target application is read in, recorded in the kernel, and bound to the target application. Therefore, the application loader can match the interface call permissions of the target application in the configuration file of the target application with the interface type corresponding to the target application in the authorization file. Only when the match is successful, the application loader can create an interface whitelist of the target application in the kernel, that is, write multiple interfaces that the target application expects to call in the configuration file into the interface whitelist of the target application.

[0066] For example, if the target application's interface call permission is a public permission, and the interface type corresponding to the target application in the authorization file is a public type, the application loader determines that the match is successful, and then the application loader can write the public interface that the target application expects to call under the public permission into the target application's interface whitelist. If the target application's interface call permission is a protected permission, and the interface type corresponding to the target application in the authorization file is not a protected permission, the application loader determines that the match fails, and at this time, the application loader does not create the target application's interface whitelist.

[0067] In some embodiments, when the interface calling permission of the target application is a protection permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the protection permission, and multiple interfaces included in the public type; when the interface calling permission of the target application is a private permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the private permission, and multiple interfaces included in the public type.

[0068] In the case where the interface type includes public type, protection type and private type, if the application is authorized by the operating system to use the public type interface, the application is a sandbox application. At this time, the application needs to configure a public interface set and can only call the public interface in the public interface set to limit the range of interfaces that the application can use. If the application is not authorized by the operating system to use the public type interface, the application belongs to a common application and can call all the public interfaces included in the public type. Correspondingly, in the case where the interface call permission is a protection permission or a private permission, that is, the target application is not authorized by the operating system to use the public type interface, at this time, the target application belongs to a common application and can call all the public interfaces included in the public type. Therefore, in this case, the interface whitelist of the target application should also include multiple interfaces that the target application expects to call under the corresponding permissions, and multiple public interfaces included in the public type. That is, the application loader needs to write the interface that the target application expects to call under the corresponding permissions recorded in the configuration file, and all the public interfaces into the interface whitelist of the target application.

[0069] For example, if the public type in the authorization file of the operating system includes 10 public interfaces, the interface calling permission of the target application is private permission, and the configuration file of the target application includes 3 private interfaces that the target application expects to call under private permission, such as interface 6, interface 7 and interface 8, then the interface whitelist of the target application created by the application loader includes 10 public interfaces and 3 private interfaces.

[0070] Figure 4 Schematic diagram of the implementation process of creating an interface whitelist provided by the embodiment of the present disclosure. Figure 4 As shown, the method includes the following steps S401 to S408.

[0071] In step S401, the application loader determines whether the current application has public permission.

[0072] It is understandable that during the application loading stage, the application loader will parse the configuration file of the application, and then match the interface call permissions in the configuration file with the interface type corresponding to the application in the authorization file of the operating system to determine whether the application has public permissions. If the application has public permissions, step S402 is executed; if the application does not have public permissions, step S403 is executed.

[0073] In step S402, a public interface whitelist is created in the kernel.

[0074] It is understandable that if the application has public authority, the set of public interfaces that the application expects to call in the configuration file is written into the interface whitelist in the kernel. If the application does not have public authority, the corresponding interface whitelist is not established, and step S403 is executed.

[0075] In step S403, the application loader determines whether the current application has protection authority.

[0076] It can be understood that if the application does not have the protection authority, step S404 is executed, and if the application has the protection authority, step S405 is executed.

[0077] In step S404, creation of a protected interface whitelist is rejected.

[0078] In step S405, a protected interface whitelist is created in the kernel.

[0079] It can be understood that if the application has protection authority, the set of protection interfaces that the application expects to call in the configuration file is written into the protected interface whitelist of the interface in the kernel, and step S406 is executed.

[0080] In addition, in some embodiments, when the application has protection permissions, the application loader can also add all public interfaces included in the public type to the public interface whitelist of the application in the kernel, so that the interface whitelist of the application can include a protected interface whitelist and a public interface whitelist.

[0081] In step S406, the application loader determines whether the current application has private permissions.

[0082] It can be understood that if the application does not have private permissions, step S407 is executed, and if the application has private permissions, step S408 is executed.

[0083] In step S407, creation of a private interface whitelist is rejected.

[0084] In step S408, a private interface whitelist is created in the kernel.

[0085] In addition, in some embodiments, when the application has private permissions, the application loader can also add all public interfaces included in the public type to the public interface whitelist of the application in the kernel, so that the interface whitelist of the application can include a private interface whitelist and a public interface whitelist.

[0086] Afterwards, the application loader may return a corresponding processing result status (eg, a success status or a failure status) to the kernel for corresponding processing.

[0087] In some embodiments, the above-mentioned kernel may also be a process manager.

[0088] In the disclosed embodiment, the interface call permission of the target application and the multiple interfaces that the target application expects to call under the interface call permission are obtained, and then based on the multiple interfaces that the target application expects to call under the interface call permission, an interface whitelist of the target application is created in the kernel of the operating system. Since the interface call permission of the target application is the type of interface that the operating system authorizes the target application to use, by assigning specific interface call permissions to the target application, the operating system can ensure that the application can only access and operate resources that are explicitly allowed. This refined permission control helps prevent unauthorized access and data leakage, thereby improving the security of the operating system. Moreover, through the whitelist mechanism, the operating system can reject interface call requests that do not meet the conditions, thereby reducing unnecessary resource consumption and helping to improve the overall performance and response rate of the operating system. In addition, since the interfaces in the whitelist are pre-authorized by the operating system, the operating system can process these interface call requests faster, thereby improving the efficiency of interface calls.

[0089] All the above optional technical solutions can be combined in any way to form optional embodiments of the present disclosure, and the embodiments of the present disclosure will not be described in detail one by one.

[0090] Based on the foregoing embodiments, the embodiments of the present disclosure provide an interface authority management device, which includes the units included and the modules included in the units, and can be implemented by a processor in an electronic device; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.

[0091] Figure 5Schematic diagram of the structure of the interface authority management device provided by the embodiment of the present disclosure. Figure 5 As shown, the interface authority management device 500 includes: an acquisition module 501 and a creation module 502, wherein:

[0092] An acquisition module 501 is used to acquire a configuration file of a target application, where the configuration file includes the interface calling permissions of the target application and a plurality of interfaces that the target application expects to call under the interface calling permissions. The interface calling permissions of the target application are the types of interfaces that the operating system authorizes the target application to use; a creation module 502 is used to create an interface whitelist of the target application in the kernel of the operating system based on the plurality of interfaces that the target application expects to call under the interface calling permissions.

[0093] In some embodiments, the creation module 502 is also used to: verify the interface call permission of the target application with the interface type corresponding to the target application in the authorization file of the operating system, the authorization file includes multiple interface types, and multiple applications corresponding to each of the multiple interface types; if the verification is passed, create an interface whitelist of the target application in the kernel, and the interfaces in the interface whitelist are the same as the interfaces that the target application expects to call under the interface call permission.

[0094] In some embodiments, multiple interface types include at least one of a public type, a protected type, and a private type, wherein the public type is used to indicate an interface type that is disclosed to multiple external applications running on the operating system, the protected type is used to indicate an interface type that is disclosed to some external applications, and the private type is used to indicate an interface type that cannot be used by external applications, and the multiple applications include external applications and internal applications of the operating system; the interface call permissions of the multiple applications include at least one of a public permission, a protected permission, and a private permission, wherein the public permission is used to indicate that the application is authorized to call an interface of a public type, the protected permission is used to indicate that the application is authorized to call an interface of a protected type, and the private permission is used to indicate that the application is authorized to call an interface of a private type.

[0095] In some embodiments, the authorization file includes interface information of multiple interfaces included in each of multiple interface types; the device also includes: a sending module for sending the authorization file to the target application, so that the target application configures the multiple interfaces that the target application expects to call under the interface call permission based on the interface type corresponding to the target application and the interface information of the multiple interfaces included in the interface type.

[0096] In some embodiments, the authorization file includes interface information of multiple interfaces included in each of multiple interface types; when the interface calling permission of the target application is protection permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the protection permission, and multiple interfaces included in the public type; when the interface calling permission of the target application is private permission, the interface whitelist of the target application includes multiple interfaces that the target application expects to call under the private permission, and multiple interfaces included in the public type.

[0097] In some embodiments, the multiple interface types are obtained by classifying multiple interfaces in the operating system according to the security levels disclosed by the interfaces.

[0098] The description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. In some embodiments, the functions or modules included in the device provided in the embodiments of the present disclosure can be used to execute the method described in the above method embodiment. For technical details not disclosed in the device embodiment of the present disclosure, please refer to the description of the method embodiment of the present disclosure for understanding.

[0099] It should be noted that in the embodiments of the present disclosure, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of the present disclosure is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiments of the present disclosure are not limited to any specific hardware, software or firmware, or any combination of hardware, software, and firmware.

[0100] Figure 6 6 is a schematic diagram of a hardware entity of an electronic device provided by an embodiment of the present disclosure. For example, the electronic device 600 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0101] Reference Figure 6, the electronic device 600 may include one or more of the following components: a processing component 601, a memory 602, a power component 603, a multimedia component 604, an audio component 605, an input / output (I / O) interface 606, a sensor component 607, and a communication component 608.

[0102] The processing component 601 generally controls the overall operation of the electronic device 600, such as operations associated with at least one of display, phone calls, data communications, camera operations, and recording operations. The processing component 601 may include one or more processors 609 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 601 may include one or more modules to facilitate the interaction between the processing component 601 and other components. For example, the processing component 601 may include a multimedia module to facilitate the interaction between the multimedia component 604 and the processing component 601.

[0103] The memory 602 is configured to store various types of data to support operations on the electronic device 600. Examples of such data include at least one of the following: instructions for any application or method operating on the electronic device 600, contact data, phone book data, messages, pictures, and videos. The memory 602 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk, or an optical disk.

[0104] The power supply component 603 provides power to various components of the electronic device 600. The power supply component 603 may include at least one of the following: a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 600.

[0105] The multimedia component 604 includes a screen that provides an output interface between the electronic device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 604 includes a front camera and / or a rear camera. When the electronic device 600 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0106] The audio component 605 is configured to output and / or input audio signals. For example, the audio component 605 includes a microphone (MIC), and when the electronic device 600 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 602 or sent via the communication component 608. In some embodiments, the audio component 605 also includes a speaker for outputting audio signals.

[0107] I / O interface 606 provides an interface between processing component 601 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, a home button, a volume button, a start button, and a lock button.

[0108] The sensor assembly 607 includes one or more sensors for providing various aspects of status assessment for the electronic device 600. For example, the sensor assembly 607 can detect the open / closed state of the electronic device 600, the relative positioning of the components, such as the display and keypad of the electronic device 600, and the sensor assembly 607 can also detect the position change of the electronic device 600 or a component in the electronic device 600, the presence or absence of contact between the user and the electronic device 600, the orientation or acceleration / deceleration of the electronic device 600, and the temperature change of the electronic device 600. The sensor assembly 607 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 607 may also include a light sensor, such as a complementary metal oxide semiconductor (CMOS) or a charge coupled device (CCD) image sensor, for use in imaging applications. In some embodiments, the sensor assembly 607 may also include, but is not limited to, at least one of the following: an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, and a temperature sensor.

[0109] The communication component 608 is configured to facilitate wired or wireless communication between the electronic device 600 and other devices. The electronic device 600 can access a wireless network based on a communication standard, such as Wi-Fi, 4G, 5G, or a combination thereof. In an exemplary embodiment, the communication component 608 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 608 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, UWB technology, Bluetooth (BT) technology and other technologies.

[0110] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application specific integrated circuits (ASIC), DSP, DSPD, programmable logic device (PLD), FPGA, controller, microcontroller, microprocessor or other electronic components.

[0111] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 602 including executable instructions or a computer program, which can be executed by a processor 609 of an electronic device 600 to perform the above method.

[0112] An embodiment of the present disclosure provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, some or all of the steps in the above method are implemented.

[0113] The embodiment of the present disclosure provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, some or all of the steps in the above method are implemented. The computer-readable storage medium can be transient or non-transient.

[0114] An embodiment of the present disclosure provides a computer program, including a computer-readable code. When the computer-readable code is executed in a computer device, a processor in the computer device executes some or all of the steps for implementing the above method.

[0115] The present disclosure provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product can be implemented specifically by hardware, software or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0116] It should be noted here that the description of the various embodiments above tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. The description of the above device, storage medium, computer program and computer program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the embodiments of the device, storage medium, computer program and computer program product disclosed in the present invention, please refer to the description of the method embodiment disclosed in the present invention for understanding.

[0117] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present disclosure. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present disclosure, the size of the serial numbers of the above-mentioned steps / processes does not mean the order of execution. The execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present disclosure. The serial numbers of the embodiments of the present disclosure are for description only and do not represent the advantages and disadvantages of the embodiments.

[0118] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0119] In the several embodiments provided in the present disclosure, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0120] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected based on actual needs to achieve the purpose of the present embodiment.

[0121] In addition, all functional units in the embodiments of the present disclosure may be integrated into one processing unit, or each unit may be separately configured as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0122] A person of ordinary skill in the art can understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks or optical disks.

[0123] Alternatively, if the above-mentioned integrated unit of the present disclosure is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present disclosure. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0124] The above description is only an implementation mode of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present disclosure, which should be included in the protection scope of the present disclosure.

Claims

1. An interface authority management method, characterized in that: The method comprises: Obtaining a configuration file of a target application, the configuration file including an interface calling permission of the target application and a plurality of interfaces that the target application expects to call under the interface calling permission, wherein the interface calling permission of the target application is an interface type that the operating system authorizes the target application to use; Based on a plurality of interfaces that the target application expects to call under the interface calling authority, an interface whitelist of the target application is created in the kernel of the operating system.

2. The method according to claim 1, characterized in that The creating an interface whitelist of the target application in the kernel of the operating system based on the multiple interfaces that the target application expects to call under the interface calling authority includes: Verifying the interface call permission of the target application with the interface type corresponding to the target application in the authorization file of the operating system, wherein the authorization file includes multiple interface types and multiple applications corresponding to each of the multiple interface types; If the verification is passed, an interface whitelist of the target application is created in the kernel, and the interfaces in the interface whitelist are the same as the interfaces that the target application expects to call under the interface calling authority.

3. The method according to claim 2, characterized in that The multiple interface types include at least one of a public type, a protected type, and a private type, wherein the public type is used to indicate an interface type that is disclosed to multiple external applications running on the operating system, the protected type is used to indicate an interface type that is disclosed to some external applications, and the private type is used to indicate an interface type that cannot be used by external applications, and the multiple applications include the external applications and internal applications of the operating system; The interface calling permissions of multiple applications include at least one of public permissions, protection permissions and private permissions. The public permissions are used to indicate that the application is authorized to call the public type of interface, the protection permissions are used to indicate that the application is authorized to call the protection type of interface, and the private permissions are used to indicate that the application is authorized to call the private type of interface.

4. The method according to claim 2, characterized in that: The authorization file includes interface information of multiple interfaces included in each of the multiple interface types; The method further comprises: The authorization file is sent to the target application, so that the target application configures multiple interfaces that the target application expects to call under the interface calling authority based on the interface type corresponding to the target application and the interface information of the multiple interfaces included in the interface type.

5. The method according to claim 3, characterized in that: The authorization file includes interface information of multiple interfaces included in each of the multiple interface types; In a case where the interface calling permission of the target application is the protection permission, the interface whitelist of the target application includes a plurality of interfaces that the target application expects to call under the protection permission and a plurality of interfaces included in the public type; In the case that the interface calling permission of the target application is the private permission, the interface whitelist of the target application includes a plurality of interfaces that the target application expects to call under the private permission and a plurality of interfaces included in the public type.

6. The method according to any one of claims 1 or 5, characterized in that: The multiple interface types are obtained by classifying multiple interfaces in the operating system according to the security levels disclosed by the interfaces.

7. An interface authority management device, characterized in that: The device comprises: an acquisition module, configured to acquire a configuration file of a target application, wherein the configuration file includes an interface calling permission of the target application and a plurality of interfaces that the target application expects to call under the interface calling permission, wherein the interface calling permission of the target application is an interface type that the operating system authorizes the target application to use; A creation module is used to create an interface whitelist of the target application in the kernel of the operating system based on a plurality of interfaces that the target application expects to call under the interface calling authority.

8. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the steps in the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps in the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program or instructions, characterized in that: When the computer program or instruction is executed by a processor, the steps in the method according to any one of claims 1 to 6 are implemented.

Images