Communication control method and apparatus, electronic device, storage medium, and program product

Abstract

The application discloses a communication control method and device, electronic equipment, storage medium and program product. The method comprises the following steps: receiving a desktop bus message, matching the desktop bus message based on a pre-registered matching rule, and determining a subject entity corresponding to the desktop bus message according to a matching result; identifying a sending subject of the desktop bus message, and determining a subject entity corresponding to the desktop bus message according to identification information corresponding to the sending subject; determining an access control mode corresponding to the subject entity and an explicit policy of the subject entity to the subject entity according to the matching rule; performing permission judgment according to the access control mode and / or the explicit policy; and performing a corresponding access control operation on the desktop bus message according to a result of the permission judgment. The application solves the technical problem that the access control granularity is coarse in the related art, cannot be accurate to the process or application package level, and it is difficult to realize fine-grained and dynamic desktop bus communication security control.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a communication control method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] D-Bus (Desktop Bus) is a widely used inter-process communication (IPC) mechanism in Linux desktop environments, providing a standardized message passing method for applications. In modern desktop operating systems, system services (such as network management, power management, and audio services) expose interfaces through D-Bus, allowing applications to obtain system status or perform system operations by calling these interfaces. With increasingly stringent security requirements for desktop operating systems, security control of D-Bus communication has become increasingly important. Malicious applications may use D-Bus interfaces to access system services or obtain sensitive system information without authorization. Therefore, fine-grained access control of D-Bus communication is necessary to ensure that only authorized applications can call specific D-Bus interfaces.

[0003] However, D-Bus communication security control schemes in related technologies have the problem of coarse access control granularity, which cannot be precise to the process or application package level, making it difficult to effectively prevent malicious applications from unauthorized access to system services or obtaining sensitive information through the D-Bus interface.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a communication control method, apparatus, electronic device, storage medium, and program product to at least solve the technical problem in the related art that the access control granularity is coarse, cannot be accurate to the process or application package level, and is difficult to achieve fine-grained and dynamic desktop bus communication security control.

[0006] According to one aspect of the embodiments of this application, a communication control method is provided, comprising: receiving a desktop bus message; matching the desktop bus message based on pre-registered matching rules; determining an object entity corresponding to the desktop bus message based on the matching result, wherein the object entity is used to characterize the accessed desktop bus resource; identifying the sending body of the desktop bus message; determining the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending body; determining an access control mode corresponding to the object entity based on the matching rules; and determining an explicit policy matching the correspondence between the subject entity and the object entity in the matching rules based on the correspondence between the subject entity and the object entity, wherein the explicit policy is used to characterize the specific access rights of the subject entity to the object entity; performing a permission determination based on the access control mode and / or the explicit policy; wherein the permission determination is used to determine the access rights of the sending body to the object entity; and performing a corresponding access control operation on the desktop bus message based on the result of the permission determination.

[0007] Optionally, before receiving desktop bus messages, the method further includes: loading definition files for subject entities and object entities, as well as policy configuration files, from a multi-level configuration directory. The multi-level configuration directory contains various configurations with different priorities, each containing different definition files and policy configuration files. Subject entities and object entities are defined using a unified data model. Subject entities include at least one of the following: executable file type, software package type, and sandbox application type. Object entities include at least one of the following: target service name, object path, interface name, and method name. The method also involves merging multiple configurations with different priorities in ascending order of priority. This merging includes: accumulating and merging policy entries for different object entities from the same subject entity; and having higher-priority configurations override lower-priority configurations for policy entries from the same subject entity to the same object entity. Finally, the merged definition files for subject entities, object entities, and policy configuration files are converted into matching rules for matching and permission determination when desktop bus messages arrive.

[0008] Optionally, converting the merged definition files of the subject entity, object entity, and policy configuration file into matching rules includes: parsing the entity attributes of the object entity, directly mapping entity attributes without regular expressions to key-value pairs of object matching rules, retaining entity attributes containing regular expressions for regular expression matching verification during the message inspection stage, and generating independent object matching rules for each access member when the object entity contains multiple access members; converting the subject identification information in the definition file of the subject entity into subject matching rules, wherein the subject matching rules are used to identify the corresponding subject entity based on the identification information of the sending subject during the message inspection stage; converting the policy configuration and access control mode of the object entity in the policy configuration file into policy matching rules, wherein the policy matching rules are used to determine permissions based on the identified subject entity and object entity during the message inspection stage; after converting the merged definition files of the subject entity, object entity, and policy configuration file into matching rules, the method further includes: registering the object matching rules, subject matching rules, and policy matching rules to the desktop bus daemon.

[0009] Optionally, the method further includes: listening for file change events in the multi-level configuration directory, wherein the file change events include at least one of the following: file creation, modification, deletion, and movement; upon detecting a file change event, reloading the definition files of the subject entity and object entity, as well as the policy configuration file, from the multi-level configuration directory, and merging them according to priority; converting the re-merged definition files of the subject entity, object entity, and policy configuration file into new matching rules; replacing the currently effective matching rules with the new matching rules, and notifying the desktop bus daemon to refresh so that the new matching rules take effect on subsequent desktop bus messages.

[0010] Optionally, matching desktop bus messages based on pre-registered matching rules and determining the object entity corresponding to the desktop bus message based on the matching result includes: comparing the registered matching rules with the message attributes of the desktop bus message, wherein the matching rules include key-value pairs converted from entity attributes in the object entity that do not contain regular expressions; if the message attributes match the key-value pairs in the matching rules, a preliminary match is determined to be successful, triggering the message checking stage; in the message checking stage, the attribute values ​​in the desktop bus message corresponding to the regular expressions retained in the object entity are extracted, and regular expression matching verification is performed; if the regular expression matching verification passes, the object entity corresponding to the desktop bus message is determined based on the entity identifier encoded in the matching rules.

[0011] Optionally, the main entity includes at least one of the following: executable file type, software package type, and sandbox application type; determining the main entity corresponding to the desktop bus message based on the identification information corresponding to the sending entity includes: obtaining the identification information corresponding to the sending entity, wherein the identification information includes at least one of the following: process identifier, executable file path; detecting whether the sending entity contains sandbox application characteristics based on the identification information; if the sending entity contains sandbox application characteristics, extracting the sandbox application identifier, and matching the main entity of the sandbox application type in the matching rules based on the sandbox application identifier; if the sending entity does not contain sandbox application characteristics, or if no corresponding main entity is matched based on the sandbox application identifier, matching other types of main entities according to a preset priority order based on the identification information, and determining the other types of main entities that are successfully matched as the main entity corresponding to the identification information.

[0012] Optionally, the access control modes include: whitelist mode and blacklist mode; the explicit policy includes at least one of the following: access permission information, validity period, and context constraints; the permission determination based on the access control mode and / or explicit policy includes: when an explicit policy exists, verifying whether the validity period has expired and verifying whether the context constraints are met, wherein the context constraints include runtime environment state constraints, and verifying whether the context constraints are met by comparing the current system runtime environment with the expected values ​​in the context constraints; when the validity period has not expired and the context constraints are met, determining that the subject entity has the access permission corresponding to the access permission information of the object entity; when there is no explicit policy, or the validity period has expired, or the context constraints are not met, determining the access permission of the subject entity to the object entity based on the default behavior corresponding to the access control mode, wherein the default behavior in whitelist mode is to allow access, and the default behavior in blacklist mode is to deny access.

[0013] According to another aspect of the embodiments of this application, a communication control device is also provided, comprising: an object matching module, configured to receive a desktop bus message, match the desktop bus message based on pre-registered matching rules, and determine the object entity corresponding to the desktop bus message according to the matching result, wherein the object entity is used to characterize the accessed desktop bus resource; a subject matching module, configured to identify the sending subject of the desktop bus message, and determine the subject entity corresponding to the desktop bus message according to the identification information corresponding to the sending subject, wherein the subject entity corresponds to the application entity that initiated the access request; a permission judgment module, configured to determine the access control mode corresponding to the object entity according to the matching rules, and determine an explicit policy matching the correspondence between the subject entity and the object entity in the matching rules according to the correspondence between the subject entity and the object entity, wherein the explicit policy is used to characterize the specific access rights of the subject entity to the object entity; perform permission judgment according to the access control mode and / or the explicit policy, wherein the permission judgment is used to determine the access rights of the sending subject to the object entity; and an access control module, configured to perform corresponding access control operations on the desktop bus message according to the result of the permission judgment.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes a communication control method during runtime.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes a communication control method by running the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of a communication control method.

[0017] In this embodiment, desktop bus messages are received, matched based on pre-registered matching rules, and the object entity corresponding to the desktop bus message is determined according to the matching result. The object entity represents the accessed desktop bus resource. The sending body of the desktop bus message is identified, and the subject entity corresponding to the desktop bus message is determined based on the identification information corresponding to the sending body. The subject entity corresponds to the application entity that initiated the access request. The access control mode corresponding to the object entity is determined according to the matching rules, and an explicit policy matching the correspondence between the subject entity and the object entity is determined in the matching rules. The explicit policy represents the specific access permissions of the subject entity to the object entity. The process is repeated based on the access control mode and / or the explicit policy. The policy performs permission determination, which determines the sending subject's access permissions to the object entity. Based on the permission determination result, corresponding access control operations are performed on desktop bus messages. By establishing a unified abstract model of subject and object entities, the access policy of the subject to the object is automatically converted into an executable matching rule within the desktop bus. Based on process-level identification information, the sending subject is accurately identified to the application granularity. By combining access control mode and explicit policy for permission determination, the policy achieves fine-grained access control at the application granularity level for desktop bus communication and supports dynamic hot updates of policies. This solves the technical problem in related technologies where the access control granularity is coarse, unable to be accurate to the process or application package level, and difficult to achieve fine-grained and dynamic desktop bus communication security control. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal (or electronic device) for implementing a communication control method according to an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of a communication control method flow according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the overall architecture of a D-Bus communication control system based on subject-object rule matching, according to an embodiment of this application.

[0022] Figure 4 This is a schematic diagram of a configuration loading and merging process provided according to an embodiment of this application;

[0023] Figure 5This is a schematic diagram of a message permission check process provided according to an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of a communication control device provided according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] To facilitate a better understanding of the embodiments of this application by those skilled in the art, some technical terms or nouns involved in the embodiments of this application are explained as follows:

[0028] D-Bus: A message bus system used for inter-process communication in the Linux desktop environment;

[0029] Match Rule: D-Bus message matching rules, used to filter and match specific types of D-Bus messages.

[0030] In related technologies, the security control of desktop bus communication mainly includes the following schemes: First, DBusdaemon static configuration, which defines which users or applications can send or receive specific D-Bus messages through XML configuration files. However, this scheme has a coarse-grained access control, only supporting user and user group-based permission control, and cannot be precise to the specific process or application package level. Moreover, after modifying the configuration, the service needs to be restarted for it to take effect, lacking dynamic update capabilities. Second, application-layer permission checks, where the permission verification logic is implemented by the application itself, resulting in inconsistent development standards and dispersed security responsibilities. Third, SELinux / AppArmor policies, which control process system calls through kernel-level security modules, but the configuration is complex and does not match the semantics of D-Bus, making debugging difficult. Fourth, the Polkit framework, which focuses on user authorization rather than inter-process communication control, and cannot achieve fine-grained interface-level control.

[0031] As described above, the existing technologies suffer from coarse-grained access control, failing to achieve precision down to the process or application package level. This makes it difficult to effectively prevent malicious applications from unauthorized access to system services or obtaining sensitive information through the D-Bus interface. Furthermore, existing solutions lack a unified subject / object abstraction model, and their configuration formats are out of sync with business scenarios, resulting in high learning costs and management complexity. In addition, existing solutions largely rely on static configuration or service restarts to update policies, lacking dynamic update mechanisms and hindering hot policy updates, impacting system availability. They also lack unified management capabilities for new application forms such as sandbox applications, making it difficult to form a closed loop of "policy definition - policy issuance - real-time execution," ultimately hindering the achievement of fine-grained, dynamic desktop bus communication security control.

[0032] To address the aforementioned issues, this application provides a solution that utilizes a three-layer architecture—entity abstraction layer, policy management layer, and message execution layer—to achieve fine-grained access control for D-Bus communication. This solution has been successfully applied to the desktop environments of several vendors' operating systems, serving as a core component of the secure access control manager system and providing security protection for system desktop bus communication. It demonstrates high feasibility and effectiveness. A detailed description follows.

[0033] According to an embodiment of this application, a method embodiment for communication control is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] The method embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1A hardware structure block diagram of a computer terminal (or electronic device) for implementing a communication control method is shown. Figure 1 As shown, the computer terminal 10 (or electronic device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0035] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or electronic device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0036] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the communication control method in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned communication control method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0037] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0038] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or electronic device).

[0039] Under the above operating environment, this application provides a communication control method. Figure 2 This is a schematic diagram of a communication control method flow according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0040] Step S202: Receive desktop bus messages, match desktop bus messages based on pre-registered matching rules, and determine the object entity corresponding to the desktop bus message according to the matching result. The object entity is used to represent the accessed desktop bus resource.

[0041] In this embodiment, the pre-registered matching rules serve as a bridge connecting messages and resources. Through the rule matching process, abstract message data can be transformed into identification results for specific object entities. As an abstract representation of the accessed resource, the identification of the object entity means that the system has clearly identified the specific service or interface targeted by the current communication behavior, which is the basis for subsequent subject identification and permission determination.

[0042] Step S204: Identify the sending body of the desktop bus message, and determine the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending body, wherein the subject entity corresponds to the application entity that initiated the access request;

[0043] This step aims to identify the source of the message, ensuring that subsequent access control can accurately target the specific application entity.

[0044] Step S206: Based on the matching rules, determine the access control mode corresponding to the object entity, and based on the correspondence between the subject entity and the object entity, determine the explicit policy that matches the correspondence in the matching rules, wherein the explicit policy is used to characterize the specific access permissions of the subject entity to the object entity.

[0045] Step S208: Perform permission determination based on access control mode and / or explicit policy, wherein the permission determination is used to determine the sending subject's access rights to the object entity.

[0046] Step S210: Based on the permission determination result, perform the corresponding access control operation on the desktop bus message.

[0047] Specifically, when the permission determination result is "access allowed," the desktop bus message continues to be delivered to the target D-Bus service; when the permission determination result is "access denied," a D-Bus error message is returned to the caller, and the message is no longer delivered. This differentiated processing mechanism based on the determination result enables fine-grained access control of D-Bus communication during the message routing phase, effectively intercepting unauthorized or excessive D-Bus calls, thereby ensuring the secure isolation of system services.

[0048] Through the above process steps, by establishing a unified abstract model of subject and object entities, the access policy of the subject to the object is automatically converted into an executable matching rule within the desktop bus. Based on process-level identification information, the sending subject is accurately identified to the application granularity. By combining access control mode and explicit policy for permission determination, the goal of fine-grained access control at the application granularity level for desktop bus communication is achieved, and the policy is supported for dynamic hot updates. This solves the technical problem in related technologies where the access control granularity is coarse and cannot be accurate to the process or application package level, making it difficult to achieve fine-grained and dynamic desktop bus communication security control.

[0049] The communication control method in steps S202 to S210 of the embodiments of this application will be further described below.

[0050] The communication control method in the embodiments of this application can be achieved by means of... Figure 3 The communication control system architecture shown is used to implement this, such as Figure 3As shown, this architecture includes multiple layers such as the application layer, inter-process communication (IPC) layer, policy management layer, and configuration storage layer. The application layer can deploy multiple applications, such as application A, application B, and application C. These applications can communicate with the IPC communication layer via D-Bus calls. The IPC communication layer includes the D-Bus system bus (libusec-ac permission check), which embeds the permission check shared library (libusec-ac) to provide desktop bus message permission checks and perform message-level access control. The policy management layer includes the policy management daemon (AccessControl...). The system comprises a D-Bus service, a configuration management module (ConfigManager), and an AdapterManager plugin management module. These modules provide management interfaces and are responsible for configuration management, policy distribution, and change notifications. The ConfigManager module loads and merges configurations from the configuration storage layer, while the AdapterManager module manages related plugin adaptations. The configuration storage layer uses a multi-level configuration directory, which may include: default package configurations ( / usr / share / uos / usec / (default package - low priority)), administrator-overridden configurations ( / etc / uos / usec / (administrator overridden - medium priority)), and runtime-modified configurations ( / var / lib / uos / usec / (runtime-modified - high priority)). At system startup, the ConfigManager module loads and merges configurations from these multi-level directories, converting them into pre-registered matching rules. The communication control method in this embodiment is described in detail below, based on this architecture.

[0051] In this embodiment, before receiving desktop bus messages, the system needs to pre-load, merge, and transform configuration data to build a basic data environment for message-level admission control. The configuration merging process is as follows.

[0052] In some embodiments of this application, before receiving a desktop bus message, the method further includes: loading definition files of subject entities and object entities, as well as policy configuration files, from a multi-level configuration directory. The multi-level configuration directory contains multiple configurations with different priorities, each containing a different definition file and policy configuration file. Subject entities and object entities are defined using a unified data model. Subject entities include at least one of the following: executable file type, software package type, and sandbox application type. Object entities include at least one of the following: target service name, object path, interface name, and method name. The method involves merging multiple configurations with different priorities at the field level, in ascending order of priority. This field-level merging includes: accumulating and merging policy entries for different object entities from the same subject entity, and having higher-priority configurations override lower-priority configurations for policy entries from the same subject entity to the same object entity. The merged definition files of subject entities, object entities, and policy configuration files are then converted into matching rules for matching and permission determination when a desktop bus message arrives.

[0053] Specifically, the configuration storage layer contains multi-level configuration directories. Each level of the configuration directory contains: definition files for subject entities and object entities, and policy configuration files (in this embodiment, the policy configuration files may include, but are not limited to, information such as the access control mode of the object entity and the explicit policy of the subject to the object). This embodiment uses a three-level configuration directory as an example. This three-level configuration directory may include: a default configuration directory for software packages (e.g., / usr / share / uos / usec / , lowest priority), an administrator-overridden configuration directory (e.g., / etc / uos / usec / , medium priority), and a runtime-modified configuration directory (e.g., / var / lib / uos / usec / , highest priority). Each level of the configuration directory contains an entity definition directory (entity.d / , used to store the definition files for subject entities and object entities), a mode configuration directory (mode.d / , used to store the access control mode of the object entity), and a policy configuration directory (policy.d / , used to store the explicit policy of the subject to the object).

[0054] For example, the layout of a three-level configuration directory can be as follows:

[0055] " / usr / share / uos / usec / # Default package configuration (lowest priority)"

[0056] ├── entity.d / # Entity definition

[0057] ├── mode.d / # Mode configuration

[0058] └── policy.d / # Policy configuration

[0059] / etc / uos / usec / # Administrator override configuration (medium priority)

[0060] └── ... (The directory structure is the same as above)

[0061] / var / lib / uos / usec / # Runtime configuration modification (highest priority)

[0062] └── ... (The directory structure is the same as above)

[0063] It should be noted that the three-level configuration directory described here is merely an illustrative example. The priority of the three-level configuration can be adjusted to two or four levels, etc., according to actual needs. For example, a configuration level at the software source level can be added, or it can be simplified to two levels: package configuration and administrator configuration. This application embodiment does not impose any limitations on this.

[0064] The configuration merging process in this embodiment is as follows: Figure 4 As shown, when the system starts up or detects a configuration change, it first initializes the configuration cache, and then scans and loads configuration directories at each level in order of priority from low to high. For example, the system may first scan the default configuration directory of the software package (e.g., / usr / share / uos / usec / , lowest priority), and load the entity definition files in the entity.d / directory, the mode configuration files in the mode.d / directory, and the policy configuration files in the policy.d / directory; then it scans the administrator-overridden configuration directory (e.g., / etc / uos / usec / , medium priority), and loads the corresponding configurations in its directory structure that are the same as those in entity.d / , mode.d / , and policy.d / ; finally, it scans the runtime modified configuration directory (e.g., / var / lib / uos / usec / , highest priority), and loads the runtime configurations in its directory structure that are the same as those in entity.d / , mode.d / , and policy.d / . Each configuration directory has a unified directory structure, containing three subdirectories: entity.d / (entity definition), mode.d / (mode configuration), and policy.d / (policy configuration). These are used to store the definitions of the subject and object entities, the access control mode of the object entity, and the explicit policy of the subject to the object, respectively.

[0065] After loading is complete, the system uses the lowest priority package's default configuration as a baseline, then sequentially merges the medium-priority administrator overriding configuration and the highest-priority runtime modification configuration at the field level to generate the final configuration cache. After merging, the system can also execute notification policy changes to trigger updates and refreshes of subsequent matching rules, ensuring the new configuration applies to subsequent desktop bus messages.

[0066] It is important to note that the merging rules vary depending on the configuration type: For subject-object definition configurations and object pattern configurations, a field-level non-empty overriding method can be used, where non-empty fields in the high-priority configuration overwrite the corresponding fields in the low-priority configuration; for policy configurations, a combination of overriding and accumulation can be used. Specifically, if the same subject targets different objects, policy entries are accumulated and merged; if the same subject targets the same object, the high-priority configuration overwrites the low-priority configuration.

[0067] For example, during the policy configuration merging process, if a low-priority software package's default configuration allows an application to access all interfaces, while a high-priority administrator's overriding configuration only allows it to access specific interfaces, then according to the rule that the higher priority policy overrides the lower priority policy when the same subject targets the same object, the final effective policy will be the scope defined by the higher priority configuration. Similarly, if a low-priority configuration already has an access policy for object A, and the same subject adds an access policy for object B in the high-priority configuration, then according to the rule that the same subject accumulates policies for different objects, the subject will ultimately have corresponding policies for both object A and object B.

[0068] In the above configuration, both the subject and object entities are defined using a unified data model, such as JSON format (in addition to JSON, entity and policy definitions can also be stored in XML, YAML, or binary formats; this embodiment does not impose any restrictions on this). Each entity includes fields such as name, type, subtype, attributes, and available operations. The subject entity (Subject) represents the application entity that initiates the access request, i.e., the process or application that initiates the D-Bus call. Its type includes at least executable file path type (identifying ordinary applications through executable file path), package type (identifying applications through package name), and sandbox application type (identifying sandbox applications through sandbox application). The object entity (Object) represents the accessed desktop bus resource, i.e., the accessed D-Bus resource, mainly including the D-Bus service type. Its attributes include at least interface-level attributes such as target service name, object path, interface name, and method name.

[0069] For example, the data structure of the main entity can be as follows:

[0070] Type 1: Executable file type

[0071] {

[0072] "name": "system-tools",

[0073] "type": "subject",

[0074] "subtype": "exe",

[0075] "attrs": {

[0076] "exes": [" / usr / bin / tool-a", " / usr / bin / tool-b"]

[0077] },

[0078] "available_operations": ["allow", "deny"]}

[0079] Type 2: Package Type

[0080] {

[0081] "name": "office-suite",

[0082] "type": "subject",

[0083] "subtype": "package",

[0084] "attrs": {

[0085] "exes": [" / usr / bin / office-writer"],

[0086] "exclude_exes": [" / usr / bin / office-calc"],

[0087] "additional_exes": [" / usr / bin / office-viewer"]

[0088] },

[0089] "available_operations": ["allow", "deny"]}

[0090] Type 3: Sandbox Application Type

[0091] {

[0092] "name": "deepin-music",

[0093] "type": "subject",

[0094] "subtype": "linglong-package",

[0095] "attrs": {

[0096] "linglong_applicationid": "com.deepin.music"

[0097] },

[0098] "available_operations": ["allow", "deny"]

[0099] }

[0100] The data structure of the object entity may be as follows:

[0101] {

[0102] "name": "example-service",

[0103] "type": "object",

[0104] "subtype": "dbus",

[0105] "attrs": {

[0106] "dbus_type": "session",

[0107] "dbus_msg_type": "method_call",

[0108] "dbus_destination": "org.example.Service",

[0109] "dbus_path": " / org / example / Service",

[0110] "dbus_interface": "org.example.Service",

[0111] "dbus_members": ["Method1", "Method2"]

[0112] },

[0113] "available_operations": ["allow", "deny"]

[0114] }

[0115] In addition, the data structure for the above strategy configuration can be as follows:

[0116] {

[0117] "object": "example-service",

[0118] "mode": "blacklist"

[0119] }

[0120] The data structure for policy configuration can be as follows:

[0121] {

[0122] "policies": [{

[0123] "subject": {"name": "office-suite"},

[0124] "objects": [{

[0125] "object": "example-service",

[0126] "operations": ["allow"]

[0127] }]

[0128] }]

[0129] }

[0130] Through the aforementioned three-level configuration priority mechanism and differentiated merging rules, this application embodiment achieves unified management of software package default policies, administrator overriding policies, and runtime modification policies, forming an integrated and interconnected policy lifecycle management system across installation, configuration, and runtime states. Simultaneously, by using a unified data model to abstract the subject and object entities, management chaos caused by scattered configurations or inconsistent formats is avoided, and clear adjudication is ensured in the event of policy conflicts. This provides a fine-grained and dynamic security control configuration foundation for desktop bus communication.

[0131] Furthermore, the system can convert the merged subject entity definition, object entity definition, and policy configuration into pre-registered matching rules, that is, automatically convert the upper-layer access policy into D-Bus internal executable matching rules, complete the admission decision during the message routing stage, so that matching and permission determination can be performed when desktop bus messages arrive, as detailed below.

[0132] In some embodiments of this application, converting the merged definition files of the subject entity, object entity, and policy configuration file into matching rules includes: parsing the entity attributes of the object entity; directly mapping entity attributes without regular expressions to key-value pairs of object matching rules; retaining entity attributes containing regular expressions for regular expression verification during the message inspection stage; and generating independent object matching rules for each access member when the object entity contains multiple access members; converting the subject identification information in the definition file of the subject entity into subject matching rules, wherein the subject matching rules are used to identify the corresponding subject entity based on the identification information of the sending subject during the message inspection stage; converting the policy configuration and access control mode of the object entity in the policy configuration file into policy matching rules, wherein the policy matching rules are used to determine permissions based on the identified subject entity and object entity during the message inspection stage; after converting the merged definition files of the subject entity, object entity, and policy configuration file into matching rules, the method further includes: registering the object matching rules, subject matching rules, and policy matching rules to the desktop bus daemon.

[0133] Specifically, the entity attributes of the object entity can be parsed first, and differentiated based on attribute characteristics: for ordinary attributes that do not contain regular expressions, they are directly mapped to key-value pairs of object matching rules. For example, the message type attribute is mapped to the type key-value pair in the matching rule, the target service name attribute is mapped to the target service name key-value pair, the object path attribute is mapped to the path key-value pair, the interface name attribute is mapped to the interface key-value pair, the listener attribute is added directly, and the method name attribute is mapped to the member key-value pair. The actual processed attributes are shown in the table below.

[0134]

[0135] For attributes containing regular expression wildcards (such as interface names with asterisks), since the desktop bus's native matching rules do not support regular expressions, and in order to meet the flexibility requirements of pattern matching (such as matching multiple similar paths or interface names), the attribute is not converted into a matching rule, but is retained until the message inspection stage for regular expression matching verification.

[0136] Furthermore, when an object entity defines multiple access members (such as multiple method names dbus_members), an independent object matching rule is generated for each access member (member), thereby ensuring that each rule matches independently and does not affect each other, achieving precise control and flexible configuration of different access members.

[0137] For example, suppose an object is defined and configured (in JSON) as follows:

[0138]

[0139] Because dbus_interface contains regular expression characters Therefore, this attribute does not participate in the matching rule transformation; and since dbus_members contains two methods, it is split into two rules, and the corresponding output matching rules are as follows:

[0140]

[0141] During the message inspection phase, after a message matches the above rules, it is also necessary to verify whether the message's interface matches the regular expression org.example. .

[0142] Meanwhile, the system can also convert the subject identification information (such as executable file path, package name or sandbox application identifier, etc.) in the subject entity definition into subject matching rules. These subject matching rules are used to identify the corresponding subject entity based on the identification information of the sending subject during the message inspection phase.

[0143] Furthermore, the system converts the policy configuration and the access control mode of the object entity into policy matching rules. In this embodiment, the policy configuration can be in JSON format, and its main fields are shown in the table below.

[0144]

[0145] The policy configuration includes information such as version number, policy list, subject entity name, object permission list, allowed operations, permission validity period, permission grant timestamp, and context constraints. Specifically, when a policy entry contains context constraints (the `constraints` field), the policy matching rule also includes constraint type, comparison operator, and expected value. These are used to verify whether all constraints are satisfied before executing the permission determination. If any constraint is not satisfied, the policy entry is skipped, and the permission reverts to the default behavior (blacklist / whitelist) corresponding to the object pattern.

[0146] For example, suppose a certain strategy is configured as follows:

[0147] {

[0148] "version": "1.0",

[0149] "policies": [

[0150] {

[0151] "subject": {

[0152] "name": "deepin-camera"

[0153] },

[0154] "objects": [

[0155] {

[0156] "object": "camera-service",

[0157] "operations": ["allow"],

[0158] "valid_period": 0,

[0159] "timestamp": 0,

[0160] "constraints": [

[0161] {

[0162] "type": "screen-locked",

[0163] "operator": "eq",

[0164] "value": "false"

[0165] } ]

[0167] } ]

[0169] },

[0170] {

[0171] "subject": {

[0172] "name": "office-suite"

[0173] },

[0174] "objects": [

[0175] {

[0176] "object": "camera-service",

[0177] "operations": ["deny"],

[0178] "valid_period": 3600,

[0179] "timestamp": 1700000000

[0180] } ]

[0182] } ]

[0184] }

[0185] In this policy configuration, the subject deepin-camera is configured to allow access to the object camera-service, but is subject to additional context constraints: when the screen is locked (screen-locked = true) or the session is not active, this policy entry is skipped, and the permissions revert to the default mode of the camera-service object (access is denied if whitelisted); the denial of permissions by the office-suite subject to the camera-service object is valid for 1 hour (calculated from the timestamp).

[0186] The format of the access control mode for object entities can be as follows:

[0187] {

[0188] "object": "camera-service",

[0189] "mode": "whitelist"

[0190] }

[0191] In this embodiment, access control modes may include a blacklist mode and a whitelist mode. Access is allowed by default in blacklist mode, while access is denied by default in whitelist mode. It is important to note that when a policy entry is configured with context constraints that are not met, the entry is ineffective, and permission determination reverts to the default behavior corresponding to the object mode. This design maintains semantic consistency between blacklist and whitelist modes.

[0192] Subsequently, the system can associate the generated object matching rules, subject matching rules, and policy matching rules with entity identifiers and register them with the desktop bus daemon. This allows the desktop bus daemon to perform preliminary filtering of messages based on the object matching rules during the message distribution phase. After a successful match, the daemon can quickly index the corresponding subject matching rules and policy matching rules through the entity identifiers, thereby completing subject identification and permission determination.

[0193] Through the above conversion process, this embodiment of the application achieves a seamless conversion from high-level policy definitions to executable matching rules within the desktop bus. On the one hand, by directly mapping ordinary attributes to matching rule key-value pairs, efficient filtering during the message distribution stage is ensured; on the other hand, by retaining regular expression attributes for processing during the message inspection stage, flexibility in rule matching is taken into account; simultaneously, by splitting multiple access members into multiple independent rules, fine-grained access control at the interface level is achieved. Furthermore, by uniformly converting subject identification information, policy configuration, and access control modes into associated matching rules and registering them to the desktop bus daemon, access checks can be automatically completed during the message routing stage without application layer intervention, thereby improving the flexibility, accuracy, and security of desktop bus communication control.

[0194] In addition, it should be noted that in order to achieve real-time adjustment and continuous evolution of desktop bus communication security control, this application embodiment supports not only static configuration loading at system startup, but also dynamic hot updates of policies, as detailed below.

[0195] In some embodiments of this application, the method further includes: monitoring file change events in a multi-level configuration directory, wherein the file change events include at least one of the following: file creation, modification, deletion, and movement; upon detecting a file change event, reloading the definition files of the subject entity and object entity, as well as the policy configuration file, from the multi-level configuration directory, and merging them according to priority; in an independent memory space, converting the re-merged definition files of the subject entity, object entity, and policy configuration file into new matching rules; replacing the currently effective matching rules with the new matching rules in an atomic substitution manner, and notifying the desktop bus daemon to refresh, so that the new matching rules take effect on subsequent desktop bus messages.

[0196] Specifically, the system can use a file change monitoring mechanism to monitor in real time the subdirectories under multi-level configuration directories (such as the default package configuration directory / usr / share / uos / usec / , the administrator overriding configuration directory / etc / uos / usec / , and the runtime modified configuration directory / var / lib / uos / usec / ). The monitored subdirectories include at least the entity definition directory (entity.d / , used to store the definition files of subject and object entities), the mode configuration directory (mode.d / , used to store the access control modes of object entities), and the policy configuration directory (policy.d / , used to store the explicit policies of subjects to objects). The monitored event types include at least file creation, modification, deletion, and movement.

[0197] When any file change event is detected, the system triggers the configuration reload process: rescans the above multi-level configuration directory, loads the definition files of the subject entity and the object entity and the policy configuration file in order of priority, and performs configuration merging (for example, performing non-empty field overriding for subject and object definition configuration and mode configuration, accumulating policy entries for different objects of the same subject in policy configuration, and overriding low priority for the same subject and the same object), and generates updated configuration data.

[0198] Subsequently, the system can perform cache update operations in an independent memory space: clearing old data such as the entity list, access pattern list, and subscription list in the existing cache; traversing all entities based on the re-merged configuration; rebuilding the rule index and subscription relationships; and converting the subject entity definition, object entity definition, and policy configuration into new matching rules. Once the new matching rules are fully constructed and logically verified, an atomic update strategy of building first and then replacing is adopted. The new matching rules replace the currently effective matching rules atomically, ensuring that no intermediate states are accessed during the update process. Afterward, the system notifies the desktop bus daemon to refresh the cache, so that the new matching rules immediately take effect on subsequent desktop bus messages.

[0199] Through the aforementioned dynamic hot update mechanism, this application embodiment can achieve zero-downtime policy updates. Policy changes do not require restarting the desktop bus daemon or related services, and do not affect running applications. Configuration changes take effect immediately on new messages, ensuring the real-time nature of access control. At the same time, by leveraging atomic update policies, the problem of inconsistent states during rule replacement can be avoided, ensuring the consistency and integrity of policy states, thereby improving the flexibility, real-time nature, and system stability of desktop bus communication security control.

[0200] Based on the aforementioned configuration loading and rule transformation, when a desktop bus message actually arrives, the system enters the message execution phase, completing the admission decision through fine-grained access control at the message level.

[0201] The following section further describes the fine-grained access control flow at the message level during the message execution phase in this application embodiment. For example... Figure 5 As shown, the process mainly includes three stages: object matching, subject identification, and permission determination. Specifically, after receiving a message corresponding to a desktop bus call initiated by an application, the desktop bus daemon first locates the corresponding object entity (i.e., the accessed desktop bus resource) according to pre-registered matching rules, and parses the message attributes to match and verify the object definition. If the match fails, it falls back to the access control mode of that object (i.e., the default mode). Then, it enters the subject identification stage, obtaining the sender's identification information (e.g., process ID and executable file path) to identify the caller and determine the corresponding subject entity (i.e., the application entity that initiated the access request). Next, it enters the permission determination stage, obtaining the access control mode of the object entity (e.g., blacklist / whitelist), querying the explicit policy configuration of the subject entity for that object entity, and checking the additional conditions of the explicit policy (e.g., whether the validity period has expired, whether the context constraints are met). If the additional conditions are not met, the explicit policy entry is not applicable, and it falls back to the default behavior corresponding to the aforementioned access control mode. If the additional conditions are met, it determines whether to allow or deny according to the explicit policy configuration. Finally, based on the permission determination result, it performs an allow or deny operation on the desktop bus message. The following provides a detailed explanation of each step in this process.

[0202] When a Desktop Bus (D-Bus) message arrives, the system first enters the object matching phase to determine the object entity accessed by the message (i.e., the accessed Desktop Bus resource), as follows.

[0203] In some embodiments of this application, matching desktop bus messages based on pre-registered matching rules and determining the object entity corresponding to the desktop bus message based on the matching result includes: comparing the registered matching rules with the message attributes of the desktop bus message, wherein the matching rules include key-value pairs converted from entity attributes of the object entity that do not contain regular expressions; if the message attributes match the key-value pairs in the matching rules, a preliminary match is determined to be successful, triggering a message checking phase; in the message checking phase, the attribute values ​​corresponding to the regular expressions retained in the object entity are extracted from the desktop bus message, and regular expression matching verification is performed; if the regular expression matching verification passes, the object entity corresponding to the desktop bus message is determined based on the entity identifier encoded in the matching rules.

[0204] In this embodiment, during the object matching phase, the system can employ a phased matching mechanism, dividing the matching process into preliminary matching performed by the desktop bus daemon during the message distribution phase, and regular expression matching verification performed during the message inspection phase. Specifically, the system pre-converts entity attributes in the object entity that do not contain regular expressions (e.g., message type, target service name, object path, etc.) into key-value pairs in the matching rules (e.g., mapping the target service name attribute to the target service name key, the object path attribute to the path key, and the method name attribute to the member key). Entity attributes in the object entity that contain regular expression wildcards (e.g., interface names or object paths with asterisks or other wildcards) are retained and not converted into key-value pairs in the matching rules. When a desktop bus message arrives, the desktop bus daemon compares the message attributes (e.g., target service name, object path, interface name, method name, etc.) with the key-value pairs in the matching rules during the message distribution phase. If the message attributes match the key-value pairs, the preliminary matching is considered successful, and the message inspection phase is triggered.

[0205] During the message inspection phase, the system extracts attribute values ​​from the desktop bus message that correspond to the regular expressions stored in the object entity, and performs regular expression matching verification. For example, when the interface name attribute of an object entity contains a regular expression, the system extracts the interface name attribute value of the message and verifies whether it matches the regular expression; similarly, when the object path of an object entity contains pattern matching features, the system extracts the object path of the message and performs regular expression matching verification to determine whether it conforms to a specific naming convention. Only when the regular expression matching verification passes, the system ultimately determines the object entity corresponding to the desktop bus message based on the entity identifier encoded in the matching rules; if the regular expression matching verification fails, it falls back to the access control mode (i.e., the default mode) of the object entity for processing.

[0206] Through the aforementioned phased object matching mechanism of rapid coarse screening followed by precise fine verification, this application embodiment can, on the one hand, utilize key-value pairs without regular expressions for rapid comparison during the message distribution stage, efficiently filtering out a large number of irrelevant messages at the underlying routing stage and avoiding the performance overhead caused by full scanning of complex regular expressions; on the other hand, by retaining attributes containing regular expressions for verification during the message inspection stage, it solves the problem that the desktop bus's native matching rules do not support regular expressions and therefore cannot take effect directly at the underlying level, thus improving the processing efficiency and flexibility of desktop bus messages while ensuring the accuracy of object identification.

[0207] Furthermore, entity identification is fundamental to permission determination, which requires accurately obtaining the caller's identity information. This application's embodiment can identify the calling entity through identifier information in the message. Specifically, as follows.

[0208] In some embodiments of this application, the subject entity includes at least one of the following: executable file type, software package type, and sandbox application type; determining the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending subject includes: obtaining the identification information corresponding to the sending subject, wherein the identification information includes at least one of the following: process identifier, executable file path; detecting whether the sending subject contains sandbox application characteristics based on the identification information; if the sending subject contains sandbox application characteristics, extracting the sandbox application identifier, and matching the subject entity of the sandbox application type in the matching rules based on the sandbox application identifier; if the sending subject does not contain sandbox application characteristics, or if no corresponding subject entity is matched based on the sandbox application identifier, matching other types of subject entities according to a preset priority order based on the identification information, and determining the other types of subject entities that are successfully matched as the subject entity corresponding to the identification information (the corresponding subject entity is determined and subsequent matching stops upon the first successful match).

[0209] First, it is necessary to obtain the identification information corresponding to the sending entity. Specifically, the corresponding process identifier (PID) can be obtained through the sender connection name contained in the desktop bus message header using the desktop bus's internal mechanism. Then, through the system interface, the absolute path of the sending entity's executable file can be obtained based on this process identifier. This process identifier and the executable file path together constitute the identification information used to identify the sending entity.

[0210] In addition to obtaining the executable file path and application identifier through process identifier, the subject can also be identified through security context and other means. The specific choice depends on the operating system's security framework, and this application does not impose any restrictions on this.

[0211] This application supports three subject subtypes, and their identification and matching methods are shown in the table below.

[0212]

[0213] Subsequently, the system can detect whether the sending entity contains sandbox application characteristics based on the aforementioned identification information. For example, the system checks whether the sending entity's operating environment contains a sandbox container identifier; if sandbox application characteristics are detected, the system further extracts the sandbox application identifier (e.g., the Linglong application identifier) ​​and prioritizes matching sandbox application type entity entities in the policy list (i.e., the entity identification data associated with the matching rules) based on this sandbox application identifier. Only when no matching sandbox application type entity entity is found will the system continue to match other types of entity entities based on the identification information.

[0214] If the sending entity does not contain sandbox application characteristics, or if a matching entity fails based on the sandbox application identifier, the system switches to an alternative matching path. This path matches other types of entity entities according to a preset priority order based on the identifier information. Specifically, for other types of entity entities (exe, file, or package), the system first performs exact matching of the executable file path (exe / file subtype, corresponding to executable file type entity entities), and then performs package expansion matching (package subtype, corresponding to package type entity entities). Package type matching supports exclusion lists and append lists. Upon successful matching on the first attempt, the corresponding entity is determined, and subsequent matching immediately stops, without further comparison of subsequent entity entities.

[0215] For example, when a sandbox application initiates a desktop bus call, the system obtains the process identifier and executable file path through its message header. It detects that the process contains a sandbox container identifier, then extracts the sandbox application identifier "com.deepin.music" and prioritizes searching for the sandbox application type entity in the policy list. If a match is found, the entity and its permissions are directly determined. Conversely, when a regular application initiates a call, if the system does not detect sandbox application characteristics, it sequentially performs exact matching of the executable file path and package expansion matching. If the executable file path matches the configuration path of an executable file type entity, the entity is immediately determined and the matching process terminates.

[0216] Through the aforementioned hierarchical detection and short-circuit matching mechanism, this embodiment of the application ensures clear isolation between sandbox applications and other conventional applications in terms of identification logic by prioritizing sandbox applications, avoiding misjudgments caused by type confusion, and meeting the need for unified management and fine-grained access control of sandbox applications; at the same time, the short-circuit strategy of stopping upon successful first matching reduces unnecessary rule comparisons and improves the accuracy of identifying desktop bus message senders in scenarios where multiple types of entities coexist.

[0217] After subject identification and object matching are completed, the system enters the permission determination stage to determine whether the sending subject has access rights to the object entity. Details are as follows.

[0218] In some embodiments of this application, the access control modes include: whitelist mode and blacklist mode; the explicit policy includes at least one of the following: access permission information, validity period, and context constraints; the permission determination based on the access control mode and / or explicit policy includes: when an explicit policy exists, verifying whether the validity period has expired and verifying whether the context constraints are met, wherein the context constraints include runtime environment state constraints, and verifying whether the context constraints are met by comparing the current system runtime environment with the expected value in the context constraints; when the validity period has not expired and the context constraints are met, determining that the subject entity has the access permission corresponding to the access permission information to the object entity; when there is no explicit policy, or the validity period has expired, or the context constraints are not met, determining the access permission of the subject entity to the object entity based on the default behavior corresponding to the access control mode, wherein the default behavior in whitelist mode is to allow access, and the default behavior in blacklist mode is to deny access.

[0219] Specifically, in this application example, permission determination can be based on the access control mode corresponding to the object entity and the explicit policy of the subject entity towards the object entity. The access control mode includes whitelist mode and blacklist mode: In whitelist mode, the default behavior is to deny access, allowing access only when the subject explicitly configures an allow policy, suitable for strict isolation scenarios, allowing only trusted applications to access; in blacklist mode, the default behavior is to allow access, denying access only when the subject explicitly configures a deny policy, suitable for scenarios protecting sensitive interfaces, blocking only specific applications from accessing. The explicit policy includes at least one of the following: access permission information (e.g., allow or deny operation), validity period, and context constraint conditions.

[0220] During the permission determination process, if an explicit policy exists, the system first checks whether the policy's validity period has expired, i.e., whether the current time exceeds the sum of the permission grant timestamp and the validity period. Simultaneously, it checks whether the context constraints are met, including runtime environment state constraints. The system obtains the current system runtime environment state through the runtime environment service and compares it with the expected values ​​in the context constraints to verify whether the context constraints are satisfied. Only if the validity period has not expired and all context constraints are satisfied does the system determine that the subject entity has the access permissions corresponding to the access permission information in the explicit policy for the object entity. If no explicit policy exists, or the validity period has expired, or any context constraint is not satisfied, the system reverts to the default behavior corresponding to the access control mode for determination: in whitelist mode, the default behavior is to allow access; in blacklist mode, the default behavior is to deny access.

[0221] For example, when a subject configures an explicit policy allowing access to a camera service object, and attaches a screen lock constraint (requiring the screen to be unlocked) with a permanent validity period, the system first checks that the current time has not exceeded the validity period during the permission determination phase. Then, it obtains the current screen lock status through the desktop environment service and compares it with the expected value of "unlocked." If the screen is indeed unlocked, access is granted, and the message continues to be passed to the target service. If the screen is locked, the explicit policy becomes invalid, the system reverts to the object's access control mode (e.g., in whitelist mode, access is denied by default), and returns an error message to the caller to block transmission. Similarly, when an explicit policy is configured to deny access with a validity period of 1 hour, if the current time has exceeded the sum of the permission grant timestamp and 1 hour, the policy becomes invalid due to expiration, and the system again reverts to the default behavior for determination.

[0222] Through the aforementioned permission determination mechanism, this application embodiment achieves fine-grained control over desktop bus message access requests. By introducing a dual verification mechanism of validity period verification and runtime environment state awareness, access control decisions can perceive real-time changes in the system environment. Through explicit policy expiration fallback logic, the system automatically downgrades to the default behavior of the access control mode when an explicit policy does not exist, expires, or environmental constraints are not met, maintaining the semantic consistency of the blacklist and whitelist modes. Therefore, the accuracy and robustness of communication security control in dynamic scenarios are effectively improved, avoiding the risk of unauthorized access due to policy expiration or environmental changes.

[0223] The communication control method provided in this application achieves fine-grained and dynamic security control of desktop bus communication through a three-layer architecture consisting of an entity abstraction layer, a policy management layer, and a message execution layer. In the entity abstraction layer, the system uniformly abstracts the calling process, software package, and sandbox application as the subject entity, and the called desktop bus interface as the object entity. Both are defined using a unified data model, which not only makes the configuration format intuitively correspond to the business scenario, easy to understand and maintain, but also provides a unified identification and management framework for sandbox applications, meeting the security control requirements of modern desktop operating systems for applications within isolated environments. In the message execution layer, the system further automatically converts the upper-layer access policy into executable matching rules within the desktop bus: ordinary attributes in the object entity are directly mapped to matching rule key-value pairs; attributes containing regular expressions are retained for verification during the message inspection stage; and method attributes containing multiple access members are split into multiple independent rules. Through this attribute classification processing mechanism, the system can quickly locate objects and complete access decisions based on matching rules during the message routing stage. This moves security control from the application layer to the core path of message distribution, avoiding the risk of application layer checks being bypassed. At the same time, it achieves precise access control at the interface level, effectively reducing the risk of malicious applications making unauthorized calls to sensitive interfaces.

[0224] At the policy management layer, the system employs a multi-level configuration priority mechanism, loading and merging configurations in layers according to the priority of default package configurations, administrator-overridden configurations, and runtime-modified configurations. Subject / object definitions and pattern configurations use field-level overriding, while policy configurations are accumulated or overridden based on the correspondence between subjects and objects. This layered storage and merging strategy not only achieves integrated linkage between software installation, administrator configuration, and runtime adjustments, forming a complete policy lifecycle management system, but also supports dynamic hot updates of policies: when configuration files change, the system detects the change through a listening mechanism, rebuilds the rules in an independent memory space, and updates the effective configuration using atomic replacement. Simultaneously, it notifies the desktop bus daemon to refresh the cache, allowing the new policy to take effect in real time for subsequent messages without restarting the service, reducing the impact of policy changes on system availability. Furthermore, the permission determination process introduces a context-aware mechanism. Policy entries can be configured with constraints such as runtime environment states. Before execution, the system checks whether these constraints are met. If they are met, the explicit policy is executed; otherwise, it automatically reverts to the default mode of the object entity's blacklist / whitelist. This mechanism enables access control decisions to be aware of real-time environmental information, achieving dynamic context-aware access control without changing the subject-object model. It provides precise control over access to sensitive resources such as audio and video peripherals based on environmental conditions, further enhancing the flexibility and robustness of communication security control.

[0225] According to an embodiment of this application, an embodiment of a communication control device is also provided. Figure 6 This is a schematic diagram of a communication control device according to an embodiment of this application. Figure 6 As shown, the device includes:

[0226] The object matching module 60 is used to receive desktop bus messages, match desktop bus messages based on pre-registered matching rules, and determine the object entity corresponding to the desktop bus message according to the matching result. The object entity is used to represent the accessed desktop bus resource.

[0227] The subject matching module 62 is used to identify the sending subject of the desktop bus message and determine the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending subject, wherein the subject entity corresponds to the application entity that initiated the access request;

[0228] The permission determination module 64 is used to determine the access control mode corresponding to the object entity based on the matching rules, and to determine the explicit policy that matches the correspondence between the subject entity and the object entity in the matching rules based on the correspondence between the subject entity and the object entity. The explicit policy is used to characterize the specific access permissions of the subject entity to the object entity. Permission determination is performed based on the access control mode and / or the explicit policy. The permission determination is used to determine the access permissions of the sending subject to the object entity.

[0229] Access control module 66 is used to perform corresponding access control operations on desktop bus messages based on the result of permission determination.

[0230] Optionally, before receiving desktop bus messages, the process further includes: loading definition files for subject entities and object entities, as well as policy configuration files, from a multi-level configuration directory. The multi-level configuration directory contains various configurations with different priorities, each containing different definition files and policy configuration files. Subject entities and object entities are defined using a unified data model. Subject entities include at least one of the following: executable file type, software package type, and sandbox application type. Object entities include at least one of the following: target service name, object path, interface name, and method name. The process involves merging multiple configurations with different priorities at the field level, in ascending order of priority. This field-level merging includes: accumulating and merging policy entries for different object entities from the same subject entity; and having higher-priority configurations override lower-priority configurations for policy entries from the same subject entity to the same object entity. Finally, the merged definition files for subject entities, object entities, and policy configuration files are converted into matching rules for matching and permission determination when desktop bus messages arrive.

[0231] Optionally, converting the merged definition files of the subject entity, object entity, and policy configuration file into matching rules includes: parsing the entity attributes of the object entity, directly mapping entity attributes without regular expressions to key-value pairs of object matching rules, retaining entity attributes containing regular expressions for regular expression matching verification during the message inspection stage, and generating independent object matching rules for each access member when the object entity contains multiple access members; converting the subject identification information in the definition file of the subject entity into subject matching rules, wherein the subject matching rules are used to identify the corresponding subject entity based on the identification information of the sending subject during the message inspection stage; converting the policy configuration and access control mode of the object entity in the policy configuration file into policy matching rules, wherein the policy matching rules are used to determine permissions based on the identified subject entity and object entity during the message inspection stage; after converting the merged definition files of the subject entity, object entity, and policy configuration file into matching rules, the method further includes: registering the object matching rules, subject matching rules, and policy matching rules to the desktop bus daemon.

[0232] Optionally, the communication control device is further configured to: monitor file change events in the multi-level configuration directory, wherein the file change events include at least one of the following: file creation, modification, deletion, and movement; upon detecting a file change event, reload the definition files of the subject entity and object entity, as well as the policy configuration file, from the multi-level configuration directory, and merge them according to priority; convert the re-merged definition files of the subject entity, object entity, and policy configuration file into new matching rules; replace the currently effective matching rules with the new matching rules, and notify the desktop bus daemon to refresh so that the new matching rules take effect on subsequent desktop bus messages.

[0233] Optionally, matching desktop bus messages based on pre-registered matching rules and determining the object entity corresponding to the desktop bus message based on the matching result includes: comparing the registered matching rules with the message attributes of the desktop bus message, wherein the matching rules include key-value pairs converted from entity attributes in the object entity that do not contain regular expressions; if the message attributes match the key-value pairs in the matching rules, a preliminary match is determined to be successful, triggering the message checking stage; in the message checking stage, the attribute values ​​in the desktop bus message corresponding to the regular expressions retained in the object entity are extracted, and regular expression matching verification is performed; if the regular expression matching verification passes, the object entity corresponding to the desktop bus message is determined based on the entity identifier encoded in the matching rules.

[0234] Optionally, the main entity includes at least one of the following: executable file type, software package type, and sandbox application type; determining the main entity corresponding to the desktop bus message based on the identification information corresponding to the sending entity includes: obtaining the identification information corresponding to the sending entity, wherein the identification information includes at least one of the following: process identifier, executable file path; detecting whether the sending entity contains sandbox application characteristics based on the identification information; if the sending entity contains sandbox application characteristics, extracting the sandbox application identifier, and matching the main entity of the sandbox application type in the matching rules based on the sandbox application identifier; if the sending entity does not contain sandbox application characteristics, or if no corresponding main entity is matched based on the sandbox application identifier, matching other types of main entities according to a preset priority order based on the identification information, and determining the other types of main entities that are successfully matched as the main entity corresponding to the identification information.

[0235] Optionally, the access control modes include: whitelist mode and blacklist mode; the explicit policy includes at least one of the following: access permission information, validity period, and context constraints; the permission determination based on the access control mode and / or explicit policy includes: when an explicit policy exists, verifying whether the validity period has expired and verifying whether the context constraints are met, wherein the context constraints include runtime environment state constraints, and verifying whether the context constraints are met by comparing the current system runtime environment with the expected values ​​in the context constraints; when the validity period has not expired and the context constraints are met, determining that the subject entity has the access permission corresponding to the access permission information of the object entity; when there is no explicit policy, or the validity period has expired, or the context constraints are not met, determining the access permission of the subject entity to the object entity based on the default behavior corresponding to the access control mode, wherein the default behavior in whitelist mode is to allow access, and the default behavior in blacklist mode is to deny access.

[0236] It should be noted that each module in the above-mentioned communication control device can be a program module (for example, a set of program instructions to implement a certain function) or a hardware module. For the latter, it can be manifested in the following forms, but is not limited to them: each of the above modules is manifested as a processor, or the functions of each of the above modules are implemented by a processor.

[0237] It should be noted that the communication control device provided in this embodiment can be used to execute... Figure 2 The communication control method shown above is also applicable to the embodiments of this application, and will not be repeated here.

[0238] This application embodiment also provides a non-volatile storage medium, which includes a stored computer program. The device containing the non-volatile storage medium executes the following communication control method by running the computer program: receiving a desktop bus message; matching the desktop bus message based on pre-registered matching rules; determining the object entity corresponding to the desktop bus message based on the matching result; wherein the object entity represents the accessed desktop bus resource; identifying the sending body of the desktop bus message; determining the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending body; wherein the subject entity corresponds to the application entity that initiated the access request; determining the access control mode corresponding to the object entity based on the matching rules; and determining an explicit policy matching the correspondence between the subject entity and the object entity in the matching rules based on the correspondence between the subject entity and the object entity; wherein the explicit policy represents the specific access rights of the subject entity to the object entity; performing permission determination based on the access control mode and / or the explicit policy; wherein the permission determination is used to determine the access rights of the sending body to the object entity; and performing corresponding access control operations on the desktop bus message based on the result of the permission determination.

[0239] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the communication control method described in various embodiments of this application: receiving a desktop bus message; matching the desktop bus message based on pre-registered matching rules; determining the object entity corresponding to the desktop bus message based on the matching result, wherein the object entity is used to represent the accessed desktop bus resource; identifying the sending body of the desktop bus message; and determining the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending body, wherein the subject entity corresponds to the application entity that initiated the access request; determining the access control mode corresponding to the object entity based on the matching rules, and determining an explicit policy matching the correspondence between the subject entity and the object entity in the matching rules based on the correspondence between the subject entity and the object entity, wherein the explicit policy is used to represent the specific access rights of the subject entity to the object entity; performing permission determination based on the access control mode and / or the explicit policy, wherein the permission determination is used to determine the access rights of the sending body to the object entity; and performing corresponding access control operations on the desktop bus message based on the result of the permission determination.

[0240] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0241] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0242] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0243] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0244] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0245] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0246] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A communication control method, characterized in that, include: The system receives desktop bus messages, matches the desktop bus messages based on pre-registered matching rules, and determines the object entity corresponding to the desktop bus message based on the matching results. The object entity is used to represent the accessed desktop bus resource. Identify the sending entity of the desktop bus message, and determine the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending entity, wherein the subject entity corresponds to the application entity that initiated the access request; Based on the matching rules, the access control mode corresponding to the object entity is determined, and based on the correspondence between the subject entity and the object entity, an explicit policy matching the correspondence is determined in the matching rules, wherein the explicit policy is used to characterize the specific access rights of the subject entity to the object entity. Permission determination is performed based on the access control mode and / or the explicit policy, wherein the permission determination is used to determine the sending subject's access rights to the object entity; Based on the permission determination result, perform corresponding access control operations on the desktop bus message.

2. The communication control method according to claim 1, characterized in that, Before receiving desktop bus messages, the method further includes: The definition files of the subject entity and the object entity, as well as the strategy configuration file, are loaded from the multi-level configuration directory. The multi-level configuration directory contains a variety of configurations with different priorities. The configurations with different priorities contain different definition files and strategy configuration files. The subject entity and the object entity are defined using a unified data model. The subject entity includes at least one of the following: executable file type, package type, and sandbox application type. The object entity includes at least one of the following: target service name, object path, interface name, and method name. According to the priority from low to high, the various configurations with different priorities are merged at the field level. The field-level merging includes: accumulating and merging the policy entries of the same subject entity on different object entities, and the policy entries of the same subject entity on the same object entity are overridden by the low-priority configuration by the high-priority configuration. The merged definition files of the main entity, the object entity, and the policy configuration file are converted into the matching rules for matching and permission determination when desktop bus messages arrive.

3. The communication control method according to claim 2, characterized in that, Converting the merged definition files of the subject entity, object entity, and strategy configuration file into the matching rules includes: The entity attributes of the object entity are parsed, and entity attributes that do not contain regular expressions are directly mapped to key-value pairs of object matching rules. Entity attributes that contain regular expressions are retained until the message inspection stage for regular expression matching verification. In the case that the object entity contains multiple access members, an independent object matching rule is generated for each access member. The entity identification information in the definition file of the entity is converted into entity matching rules, wherein the entity matching rules are used to identify the corresponding entity based on the identification information of the sending entity during the message inspection phase; The policy configuration in the policy configuration file and the access control mode of the object entity are converted into policy matching rules, wherein the policy matching rules are used to determine permissions based on the identified subject entity and object entity during the message inspection phase. After converting the merged definition files of the subject entity, object entity, and strategy configuration file into the matching rules, the process further includes: The object matching rule, the subject matching rule, and the strategy matching rule are registered to the desktop bus daemon.

4. The communication control method according to claim 2, characterized in that, The method further includes: Listen for file change events in the multi-level configuration directory, wherein the file change events include at least one of the following: file creation, modification, deletion, and movement; Upon detecting a file change event, the definition files of the subject entity and object entity, as well as the policy configuration file, are reloaded from the multi-level configuration directory and merged according to the priority. The definition files of the main entities, the definition files of the object entities, and the strategy configuration files that have been merged are converted into new matching rules; Replace the currently effective matching rule with the new matching rule and notify the desktop bus daemon to refresh so that the new matching rule applies to subsequent desktop bus messages.

5. The communication control method according to claim 1, characterized in that, The desktop bus messages are matched based on pre-registered matching rules, and the object entities corresponding to the desktop bus messages are determined according to the matching results, including: The registered matching rules are compared with the message attributes of the desktop bus messages, wherein the matching rules include key-value pairs obtained by converting entity attributes that do not contain regular expressions in the object entity; If the message attribute matches the key-value pair in the matching rule, the initial match is determined to be successful, and the message inspection phase is triggered. During the message inspection phase, the attribute values ​​in the desktop bus message that correspond to the regular expressions stored in the object entity are extracted, and regular expression matching verification is performed. If the regular expression matching verification passes, the object entity corresponding to the desktop bus message is determined based on the entity identifier encoded in the matching rule.

6. The communication control method according to claim 1, characterized in that, The main entity includes at least one of the following: executable file type, software package type, and sandbox application type; based on the identification information corresponding to the sending entity, the main entity corresponding to the desktop bus message is determined to include: Obtain the identification information corresponding to the sending entity, wherein the identification information includes at least one of the following: process identifier, executable file path; Based on the identification information, detect whether the sending entity contains sandbox application characteristics; If the sending entity contains sandbox application characteristics, extract the sandbox application identifier, and match the main entity of the sandbox application type in the matching rules based on the sandbox application identifier; If the sending entity does not contain sandbox application features, or if no corresponding entity is matched based on the sandbox application identifier, other types of entity entities are matched according to the identifier information in a preset priority order, and the successfully matched other types of entity entities are determined as the entity entity corresponding to the identifier information.

7. The communication control method according to claim 1, characterized in that, The access control modes include: whitelist mode and blacklist mode; the explicit policy includes at least one of the following: access permission information, validity period, and context constraints; permission determination based on the access control mode and / or the explicit policy includes: In the presence of the explicit policy, it is verified whether the validity period has expired and whether the context constraints are satisfied. The context constraints include runtime environment state constraints. The context constraints are verified by comparing the current system runtime environment with the expected value in the context constraints. If the validity period has not expired and the context constraint condition is met, it is determined that the subject entity has the access permission corresponding to the access permission information to the object entity; In the absence of the explicit policy, or when the validity period has expired, or when the context constraints are not met, the access rights of the subject entity to the object entity are determined according to the default behavior corresponding to the access control mode. In the whitelist mode, the default behavior is to allow access, and in the blacklist mode, the default behavior is to deny access.

8. A communication control device, characterized in that, include: The object matching module is used to receive desktop bus messages, match the desktop bus messages based on pre-registered matching rules, and determine the object entity corresponding to the desktop bus message according to the matching result, wherein the object entity is used to represent the accessed desktop bus resource. The subject matching module is used to identify the sending subject of the desktop bus message and determine the subject entity corresponding to the desktop bus message based on the identification information corresponding to the sending subject, wherein the subject entity corresponds to the application entity that initiated the access request; The permission determination module is used to determine the access control mode corresponding to the object entity based on the matching rules, and to determine an explicit policy that matches the correspondence between the subject entity and the object entity in the matching rules based on the correspondence between the subject entity and the object entity, wherein the explicit policy is used to characterize the specific access permissions of the subject entity to the object entity; and to perform permission determination based on the access control mode and / or the explicit policy, wherein the permission determination is used to determine the access permissions of the sending subject to the object entity; The access control module is used to perform corresponding access control operations on the desktop bus messages based on the result of the permission determination.

9. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the communication control method according to any one of claims 1 to 7.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the communication control method according to any one of claims 1 to 7 by running the computer program.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the communication control method according to any one of claims 1 to 7.

Images