A component permission management method based on Openharmony

Abstract

The application provides an Openharmony-based component permission management method, characterized in that, without changing the Openharmony itself architecture, a general technical solution is provided for system service and NAPI access control, specifically comprising: S1, establishing a brand-new registry different from the Openharmony original one; S2, adding an application registration operation to the BUNDLEMGR of the Openharmony system; S3, modifying the application management service appmgr and implanting an application startup permission control function; S4, modifying the NAPI framework function; S5, modifying the ACE framework; S6, modifying the SAMGR service; S7, system service component access permission configuration; S8, system service component access permission modification; S9, component state modification; the application fills the gap of the Openharmony-based system service access control component, can independently set the access permission of the system service according to the demand, the access permission of the system service can be remotely modified, the permission modification instruction can be customized, the privacy and security are guaranteed, the use method is flexible and can be used as needed, and the original system technical architecture system is not affected.

Description

Technical Field

[0001] This invention relates to the field of system service development and management in the Openharmony operating system, and more specifically to a component permission management method based on Openharmony. Background Technology

[0002] OpenHarmony is a domestically developed open-source operating system with an advanced distributed framework. However, due to its relatively recent release, its functionality is still incomplete. Particularly in financial scenarios, NAPI (New Application Programming Interface) can be called by any application with a simple signature, and there is no substantial access control for system services. This exposes some financially-oriented system services and NAPIs requiring access control to the risk of information leakage and malicious operations. Adding access control functionality to each system service and NAPI would consume a significant amount of development work, ultimately impacting overall development efficiency.

[0003] In the existing technology, system service calls are made through the Openharmony system's SAMGR, while NAPI calls are made through the BUNDLEMGR intermediary. It is necessary to integrate these two services into a single framework.

[0004] In operating systems, inter-process communication is typically conducted via a binder proxy, meaning neither process can access the other's information, thus hindering access control. A mechanism is needed to enable the called party to perceive the caller's identity and determine access permissions. Summary of the Invention

[0005] This invention, based on the Openharmony L2 (open-source HarmonyOS standard system), provides system developers with a method for managing permissions for system services and NAPI. Specifically, it's a component permission management method based on Openharmony, addressing the existing technology where system service calls are implemented through Openharmony's SAMGR (System Capability Management Service), while NAPI calls are relayed through BUNDLEMGR (System Package Management Service), requiring the integration of these two services into a single framework. Furthermore, it addresses the issue that inter-process communication in the operating system is conducted via binder (process communication suite) in a proxy manner, preventing either party from obtaining information about the other and thus hindering permission control.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A component permission management method based on Openharmony provides a general technical solution for access control of system services and NAPI without changing the Openharmony architecture itself. The method includes the following steps:

[0008] S1. Create a completely new registry that is different from the native Openharmony registry;

[0009] S2. Add application registration to the BUNDLEMGR of the Openharmony system;

[0010] S2.1 Modify the ProcessBundleInstall method of the application installation process to insert registry registration functionality after the application installation process is completed;

[0011] S2.1.1 Obtain the application's BundleName (component name) and pass it to the corresponding NAME field in the registry;

[0012] S2.1.2 Obtain the application version number and store it in the registry;

[0013] S2.1.3 Obtain the application version number, signature, description, and copyright information and store them in the registry;

[0014] S2.1.4 Determine the application type: system-preset applications are OS, and third-party applications are EXT; store them in the registry.

[0015] S2.1.5 Set the application's initial state to "In Use";

[0016] S2.1.6, Generate application security signature;

[0017] S2.1.7 Submit registration information, store it in the system's built-in database, and complete the registration.

[0018] S2.2 Modify the ProcessBundleUninstall method of the application uninstallation process to clear registry records when the application is uninstalled.

[0019] S2.2.1 Obtain application registration information via bundleName;

[0020] S2.2.2 Delete the corresponding registry information;

[0021] S2.2.3, Complete application deletion.

[0022] S3. Modify the application management service appmgr (application management service) to inject application startup permission control function;

[0023] S3.1 Obtain application registration information;

[0024] S3.2 Determine if the application has startup permissions;

[0025] S3.3 If the permission verification is successful, start the application; otherwise, end the application startup process.

[0026] S4. Modify the functionality of the NAPI framework;

[0027] S4.1 Add registration functionality when NAPI starts;

[0028] S4.1.1. Call the original system registration interface to register;

[0029] S4.1.2 Obtain NAPI name information;

[0030] S4.1.3 Initialize NAPI's type and running status information;

[0031] S4.1.4 Register NAPI in the registry of [Step S1];

[0032] S4.2, Generating Digital Signatures;

[0033] S4.2.1 Obtain the type and name of Napi;

[0034] S4.2.2, Use the BlowFinsh algorithm to generate digital signatures;

[0035] S4.3 Return the digital signature and save it to memory;

[0036] S4.4 Add NAPI access control functionality;

[0037] S4.4.1 Obtain the digital signature for accessing the NAPI application, and determine whether you have access rights based on the CID (Component Identifier Code);

[0038] S4.4.2 Applications with access permissions continue to perform NAPI call operations;

[0039] S4.4.3. Interrupt calls from applications that do not have access privileges.

[0040] S5. Modify the ACE (Cross-Platform Capability Environment) framework;

[0041] S5.1 Obtain application attribute information during application installation;

[0042] S5.2 Store the application's attribute information in the registry.

[0043] S6. Modify the SAMGR service;

[0044] S6.1 Add permission check functionality to safwk (system service framework);

[0045] S6.1.1 Obtain SAMGER agency services;

[0046] S6.1.2 Determine if the service was successfully obtained. If not, return an error message and terminate the SA (System Service) call.

[0047] S6.1.3 Obtain the system registration code and the digital signature of the SA;

[0048] S6.1.4 Determine whether access permissions are granted;

[0049] S6.2 Add permission judgment function to SAMGR;

[0050] S6.2.1 Determine if the system registration code is valid. If invalid, interrupt the call and return an error message.

[0051] S6.2.2 Determine whether access rights are granted based on the incoming digital signature.

[0052] S7, System service component access permission configuration;

[0053] S7.1 Read the initialization file for system service interface access permissions when the system starts up;

[0054] S7.2 Generate and update the CID of registered components according to the configuration file. The CID consists of the component number and the visitor's digital signature component.

[0055] S7.3 Store the CID in the corresponding field in the registry.

[0056] S8. Modify access permissions for system service components;

[0057] S8.1. Access permissions can be added by adding the visitor's digital signature to the CID of the accessed component.

[0058] S8.2. Remove the visitor's digital signature from the CID of the accessed component to remove the access permission.

[0059] S9, Modify component status.

[0060] S9.1 The STATUS field in the registration information of the accessed component defaults to 1: in use;

[0061] S9.2 Change the STATUS field in the registration information of the accessed component to 0: Disabled, then the component is disabled and in an unusable state.

[0062] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0063] This invention fills the gap in system service access control components based on Openharmony. It allows users to set access permissions for system services according to their needs, remotely modify access permissions, and customize permission modification commands, thus ensuring privacy and security. Furthermore, it is flexible in its usage and can be used as needed without affecting the original system's technical architecture. Attached Figure Description

[0064] Figure 1 This is the registry structure in step S1 of the present invention;

[0065] Figure 2 This is the startup loading process for the component management function system of the present invention;

[0066] Figure 3 This is a flowchart illustrating the permission determination process for this invention. Detailed Implementation

[0067] To clarify the technical problems, technical solutions, implementation processes, and performance demonstrations, the present invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative. The present invention is not intended to limit the scope of the invention. Various exemplary embodiments, features, and aspects of this disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the drawings denote elements with the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0068] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0069] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0070] Example 1

[0071] A component permission management method based on Openharmony provides a general technical solution for access control of system services and NAPI without changing the Openharmony architecture itself. The method includes the following steps:

[0072] S1. Create a completely new registry that is different from the native Openharmony registry;

[0073] S2. Add application registration to the BUNDLEMGR of the Openharmony system;

[0074] S2.1 Modify the ProcessBundleInstall method of the application installation process to insert registry registration functionality after the application installation process is completed;

[0075] S2.1.1 Obtain the application's BundleName and pass it to the corresponding NAME field in the registry;

[0076] S2.1.2 Obtain the application version number and store it in the registry;

[0077] S2.1.3 Obtain the application version number, signature, description, and copyright information and store them in the registry;

[0078] S2.1.4 Determine the application type: system-preset applications are OS, and third-party applications are EXT; store them in the registry.

[0079] S2.1.5 Set the application's initial state to "In Use";

[0080] S2.1.6, Generate application security signature;

[0081] S2.1.7 Submit registration information, store it in the system's built-in database, and complete the registration.

[0082] S2.2 Modify the ProcessBundleUninstall method of the application uninstallation process to clear registry records when the application is uninstalled.

[0083] S2.2.1 Obtain application registration information via bundleName;

[0084] S2.2.2 Delete the corresponding registry information;

[0085] S2.2.3, Complete application deletion.

[0086] S3. Modify the application management service appmgr to inject application startup permission control function;

[0087] S3.1 Obtain application registration information;

[0088] S3.2 Determine if the application has startup permissions;

[0089] S3.3 If the permission verification is successful, start the application; otherwise, end the application startup process.

[0090] S4. Modify the functionality of the NAPI framework;

[0091] S4.1 Add registration functionality when NAPI starts;

[0092] S4.1.1. Call the original system registration interface to register;

[0093] S4.1.2 Obtain NAPI name information;

[0094] S4.1.3 Initialize NAPI's type and running status information;

[0095] S4.1.4 Register NAPI in the registry of [Step S1];

[0096] S4.2, Generating Digital Signatures;

[0097] S4.2.1 Obtain the type and name of Napi;

[0098] S4.2.2, Use the BlowFinsh algorithm to generate digital signatures;

[0099] S4.3 Return the digital signature and save it to memory;

[0100] S4.4 Add NAPI access control functionality;

[0101] S4.4.1 Obtain the digital signature for accessing the NAPI application, and determine whether you have access rights based on the CID;

[0102] S4.4.2 Applications with access permissions continue to perform NAPI call operations;

[0103] S4.4.3. Interrupt calls from applications that do not have access privileges.

[0104] S5. Modify the ACE framework;

[0105] S5.1 Obtain application attribute information during application installation;

[0106] S5.2 Store the application's attribute information in the registry.

[0107] S6. Modify the SAMGR service;

[0108] S6.1 Add permission check functionality to safwk;

[0109] S6.1.1 Obtain SAMGER agency services;

[0110] S6.1.2 Determine if the service was successfully obtained. If not, return an error message and terminate the SA service call. S6.1.3 Obtain the system registration code and the SA's digital signature.

[0111] S6.1.4 Determine whether access permissions are granted;

[0112] S6.2 Add permission judgment function to SAMGR;

[0113] S6.2.1 Determine if the system registration code is valid. If invalid, interrupt the call and return an error message.

[0114] S6.2.2 Determine whether access rights are granted based on the incoming digital signature.

[0115] S7. Read the initialization file for system service interface access permissions when the system starts up;

[0116] S7.1 Reads the permission initialization file when the system starts up;

[0117] S7.2 Generate and update the CID of registered components according to the configuration file. The CID consists of the component number and the visitor's digital signature component.

[0118] S7.3 Store the CID in the corresponding field in the registry.

[0119] S8. Modify access permissions for system service components;

[0120] S8.1. Access permissions can be added by adding the visitor's digital signature to the CID of the accessed component.

[0121] S8.2. Remove the visitor's digital signature from the CID of the accessed component to remove the access permission.

[0122] S9, Modify component status.

[0123] S9.1 The STATUS field in the registration information of the accessed component defaults to 1: in use;

[0124] S9.2 Change the STATUS field in the registration information of the accessed component to 0: Disabled, then the component is disabled and in an unusable state.

[0125] In practical use, loading the component permission management method of this application into the operating system and starting permission management work requires the following specific loading process:

[0126] Step 1: Read the system service access permission configuration file from the specified directory when the system starts up;

[0127] Step 2: Start the access control service Module_Management;

[0128] Step 3: Determine if this is the first time the system is started. If so, the registry will be automatically generated.

[0129] Step 4: Read the system services that need to be managed from the configuration file and generate the following registration information;

[0130] 1: Number, 2: Type, 3: Name, 4: Version, 5: Signature, 6: Description, 7: Copyright, 8: Category, 9: Status, 10: Identifier;

[0131] Step 5: Read the Napi that needs to be managed from the configuration file and generate registration information. The content of the registration information is the same as in Step 4.

[0132] Step 6: Scan the pre-installed applications on the system and automatically write the pre-installed application information into the registry. The registry content is the same as in Step 4.

[0133] Step 7: Generate a CID using a symmetric block encryption algorithm. The CID consists of the component authorization ID and the caller fingerprint.

[0134] Step 8: Obtain the caller initialization information from the configuration file read in Step 1, and generate fingerprint information for the caller using an asymmetric encryption algorithm;

[0135] Step 9: Obtain the caller initialization information from the configuration file read in Step 1, and generate fingerprint information for the caller using an asymmetric encryption algorithm.

[0136] After the component permission management function of this application is loaded into the system through the above steps, the access permission verification process for accessing system components is as follows:

[0137] Step 1: The caller sends a call request. The parameters of the call request must include the caller's fingerprint and the globally unique identifier of the system service. The access control service intercepts the request before it is processed by SAMGR.

[0138] Step 2: The access control service determines whether the caller has permission to access the called service, obtains the CID of the called service, and matches it with the caller's fingerprint. If the match is successful, proceed to Step 3-1; otherwise, proceed to Step 3-2.

[0139] Step 3-1: If the verification is successful, the request service will be handed over to SAGMR for further processing, and the SAMGR proxy service will return the request result.

[0140] Step 3-2: Verification failed, end the call action.

[0141] This invention fills the gap in system service access control components based on Openharmony. It allows users to set access permissions for system services according to their needs, remotely modify access permissions, and customize permission modification commands, thus ensuring privacy and security. Furthermore, it is flexible in its usage and can be used as needed without affecting the original system's technical architecture.

[0142] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A component permission management method based on OpenHarmony, characterized in that, Without altering the OpenHarmony architecture itself, a general technical solution is provided for access control of system services and NAPI, specifically including the following steps: S1. Create a completely new registry that is different from the native Openharmony registry; S2. Add application registration to the BUNDLEMGR of the Openharmony system; Step S2 includes the following: S2.1 Modify the ProcessBundleInstall method of the application installation process to insert registry registration functionality after the application installation process is completed; S2.2 Modify the ProcessBundleUninstall method of the application uninstallation process to clear registry records when the application is uninstalled; Specifically, step S2.1 includes: S2.1.1 Obtain the application's BundleName and pass it to the corresponding NAME field in the registry; S2.1.2 Obtain the application version number and store it in the registry; S2.1.3 Obtain the application version number, signature, description, and copyright information and store them in the registry; S2.1.4 Determine the application type: system-preset applications are OS, and third-party applications are EXT; store them in the registry. S2.1.5 Set the application's initial state to "In Use"; S2.1.6, Generate application security signature; S2.1.7 Submit registration information, store it in the system's built-in database, and complete the registration; Step S2.2 specifically includes: S2.2.1 Obtain application registration information via bundleName; S2.2.2 Delete the corresponding registry information; S2.2.3, Complete application deletion; S3. Modify the application management service appmgr to inject application startup permission control function; S4. Modify the functionality of the NAPI framework; Step S4 includes the following: S4.1 Add registration functionality when NAPI starts; S4.2, Generating Digital Signatures; S4.3 Return the digital signature and save it to memory; S4.4 Add NAPI access control functionality; Step S4.1 specifically includes: S4.1.

1. Call the original system registration interface to register; S4.1.2 Obtain NAPI name information; S4.1.3 Initialize NAPI's type and running status information; S4.1.4 Register NAPI in the registry of [Step S1]; Step S4.2 specifically includes: S4.2.1 Obtain the type and name of Napi; S4.2.2, Use the BlowFinsh algorithm to generate digital signatures; Step S4.4 specifically includes: S4.4.1 Obtain the digital signature for accessing the NAPI application, and determine whether you have access rights based on the CID; S4.4.2 Applications with access permissions continue to perform NAPI call operations; S4.4.

3. Interrupt the call operation of an application without access rights; S5. Modify the ACE framework; S6. Modify the SAMGR service; S7, System service component access permission configuration; Step S7 specifically includes the following: S7.1 Read the initialization file for system service interface access permissions when the system starts up; S7.2 Generate and update the CID of registered components according to the configuration file. The CID consists of the component number and the visitor's digital signature component. S7.3 Store the CID in the corresponding field in the registry; S8. Modify access permissions for system service components; S9, Modify component status.

2. The component permission management method based on Openharmony according to claim 1, characterized in that, Step S3 specifically includes the following: S3.1 Obtain application registration information; S3.2 Determine if the application has startup permissions; S3.3 If the permission verification is successful, start the application; otherwise, end the application startup process.

3. The component permission management method based on Openharmony according to claim 1, characterized in that, Step S5 specifically includes the following: S5.1 Obtain application attribute information during application installation; S5.2 Store the application's attribute information in the registry.

4. The component permission management method based on Openharmony according to claim 1, characterized in that, Step S6 includes the following: S6.1 Add permission check functionality to safwk; S6.2 Add permission judgment function to SAMGR; Specifically, step S6.1 includes: S6.1.1 Obtain SAMGER agency services; S6.1.2 Determine if the service was successfully obtained. If not, return an error message and terminate the SA service call. S6.1.3 Obtain the system registration code and the digital signature of the SA; S6.1.4 Determine whether access permissions are granted; Step S6.2 specifically includes: S6.2.1 Determine if the system registration code is valid. If invalid, interrupt the call and return an error message. S6.2.2 Determine whether access rights are granted based on the incoming digital signature.

5. A component permission management method based on Openharmony according to claim 1, characterized in that, Step S8 specifically includes the following: S8.

1. Access permissions can be added by adding the visitor's digital signature to the CID of the accessed component. S8.

2. Remove the visitor's digital signature from the CID of the accessed component to remove the access permission.

6. The component permission management method based on Openharmony according to claim 1, characterized in that, Step S9 specifically includes the following: S9.1 The STATUS field in the registration information of the accessed component defaults to 1: In use; S9.2 Change the STATUS field in the registration information of the accessed component to 0: Disabled, then the component is disabled and in an unusable state.

Images