A method, system, and terminal device for generating injection attacks using targeted security strategies.

Abstract

This invention provides an application-oriented security policy generation and injection method, system, and terminal device, comprising: obtaining installation package information corresponding to the target application from the cloud; during the installation phase of the target application, verifying whether the target application is an application to be privileged and escalated by using the application signature and binding signature, and writing a targeted authorization state to the target application after the verification is passed; during the application process creation phase of the target application startup, reading the targeted authorization state, and selecting or generating a targeted security domain for the target application; simultaneously, switching the security context of the application process to the area corresponding to the targeted security domain, and merging the permission increment corresponding to the policy fragment into the kernel policy graph. This solution can enable targeted granting of additional permissions to specific customer applications that have passed platform review and whose identities can be verified within the scope of their installation and operation, without extending permissions to other similar applications, thus avoiding security risks.

Description

Technical Field

[0001] This invention relates to the field of application security technology, and more particularly to an application-oriented security strategy generation and injection method, system, and terminal device. Background Technology

[0002] In B2B smart hardware and industry-customized scenarios, the Android public version system typically employs a relatively strict SELinux policy to ensure baseline system security. Customer business applications are mostly aftermarket applications, whose functions often require access to sensitive resources restricted by default policies. If general domain permissions such as untrusted_app are directly relaxed in the public version policy, the expanded permissions will affect all similar applications, leading to a significant increase in the overall system attack surface.

[0003] Therefore, there is a need for a technical solution that can target specific customer applications and grant additional SELinux capabilities within the scope of their installation and operation. Summary of the Invention

[0004] The purpose of this invention is to provide an application-oriented security policy generation injection method, system, and terminal device that can grant additional SELinux capabilities to specific customer applications that have passed platform verification and whose identities can be verified within their installation and operation scope, without extending the permissions to other similar applications, thus avoiding security risks.

[0005] The technical solution provided by this invention is as follows: In a first aspect, this application provides an injection method for generating applications based on targeted security strategies, applied to a terminal device, comprising: Obtain the installation package information corresponding to the target application sent from the cloud. The installation package information includes at least the application package, the application feature code obtained by the cloud from parsing the application package, the privilege escalation configuration package generated by the cloud based on the permission request information of the target application, and the binding signature generated by the cloud by combining the application feature code and the privilege escalation configuration package and performing private key signing. During the installation phase of the target application, the application feature code and the binding signature are used to verify whether the target application is an application to be privileged. After the verification is passed, a targeted authorization status is written to the target application. The targeted authorization status includes at least setting a feature flag, recording the targeted security domain template identifier to be used, the policy fragment version number, and the hash of the allowed permission increment set. During the application process creation phase of the target application startup, the targeted authorization status is read, and a targeted security domain is selected or generated for the target application. At the same time, the security context of the application process is switched to the region corresponding to the targeted security domain, and the permission increment corresponding to the policy fragment is merged into the kernel policy graph, so that the target application runs in the targeted security domain with the target permissions.

[0006] In some implementations, the application signature includes at least the application package name, the application signature certificate chain fingerprint, and the application package file digest; The privilege escalation configuration package includes at least the following structured information: a requested targeted security domain template identifier, a policy fragment version number, a set of permission increments, a policy validity period, a channel identifier for the controlled distribution channel, and a customer identifier for the target application. The fields of the binding signature include at least the application package file digest, privilege escalation configuration package digest, policy validity period, channel identifier, customer identifier, and a random number generated by the private key signature.

[0007] In some implementations, obtaining the installation package information corresponding to the target application sent from the cloud includes: The installation package information is obtained through a controlled distribution channel based on the privilege escalation configuration package payload attached in the installation session, or based on the accompanying file with the same version number as the target application, or based on the privilege escalation configuration package byte stream submitted by the market client when calling the system privileged installation interface.

[0008] In some embodiments, the application-oriented security policy generation injection method provided in this application further includes: The privilege escalation configuration package is then encrypted a second time using the device's unique key or the session key of the installation session.

[0009] In some implementations, verifying whether the target application is an application to be privileged is performed using the application signature and the binding signature, including: Verify the binding signature and compare the application feature code with the actual characteristics of the installed target application, including application package name consistency comparison, application signature certificate chain fingerprint consistency comparison, and application package file digest consistency comparison. If the verification passes, determine that the target application is an application to be privileged.

[0010] In some implementations, reading the targeted authorization status and selecting or generating a targeted security domain for the target application includes: Read the directed authorization status to determine whether there is a valid privilege escalation configuration package information; If the determination is yes, then based on the preset policy slot and parameterization type, the information including the application package name, application signing certificate chain fingerprint, and UID range in the application security context configuration is mapped to the selected targeted security domain; or during application startup, a patch file trusted by the application security context configuration is dynamically issued or updated and policy reloading is triggered to generate the targeted security domain for the target application to run; or the privilege escalation configuration package information is compiled into a small policy fragment and merged with the baseline policy and injected through the policy loading interface supported by the kernel to generate the targeted security domain for the target application to run. If the result is negative, the standard application startup process will be used.

[0011] In some embodiments, the application-oriented security policy generation injection method provided in this application further includes: When network conditions are available, perform supplementary online verification, including checking the platform's revocation list, verifying whether the policy version is still allowed to be issued, and checking whether the time / lease is synchronized with the server. In offline scenarios, downgrade verification is performed based on the local certificate chain and signature timestamp strategy, and online verification is performed when network conditions are met later.

[0012] In some implementations, after verifying whether the target application is the application to be privileged by using the application signature and the binding signature, the method further includes: The privilege escalation configuration package data and policy index corresponding to the target application that pass the verification are written to the protected storage area, and a connection is established and recorded with fields containing application package name, customer identifier, privilege escalation configuration package version, policy validity period, and revocation token; the privilege escalation configuration package data corresponding to the target application that fails the verification shall not be written to the policy effective path.

[0013] Secondly, this application provides an application-oriented security policy generation injection system, including: a client, a remote end, and a terminal device; The client sends the target application to be published to the cloud. The terminal device obtains installation package information corresponding to the target application from the cloud. The installation package information includes at least an application package, an application feature code obtained by the cloud from parsing the application package, an privilege escalation configuration package generated by the cloud based on the permission request information of the target application, and a binding signature generated by the cloud by combining the application feature code and the privilege escalation configuration package and performing private key signing. During the installation phase of the target application, the terminal device verifies whether the target application is an application to be privileged and elevated by using the application feature code and the binding signature. After the verification is passed, the terminal device writes a targeted authorization status to the target application. The targeted authorization status includes at least setting a feature flag, recording the targeted security domain template identifier to be used, the policy fragment version number, and the hash of the allowed permission increment set. When the terminal device creates the application process during the startup phase of the target application, it reads the targeted authorization status and selects or generates a targeted security domain for the target application. At the same time, it switches the security context of the application process to the region corresponding to the targeted security domain and merges the permission increment corresponding to the policy fragment into the kernel policy graph, so that the target application runs in the targeted security domain with the target permissions.

[0014] Thirdly, this application provides a terminal device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the application-oriented security policy generation injection method described in the first aspect.

[0015] The application-oriented security strategy generation injection method, system, and terminal device provided by this invention have at least the following technical effects: 1) This application binds the application feature code (package name, signature fingerprint, binary / file digest, etc.) obtained by APK parsing to the PEP content for signature, so that the privilege escalation configuration is strongly bound to the specific application installation instance. Unlike the relaxed whole-device policy without identity constraints, it will not extend the privilege to other similar applications and avoid causing security risks. 2) This application can distribute PEPs synchronously during application installation / update through a controlled distribution channel, and complete the closed loop of unsigning, validity period and feature consistency verification and optional online supplementary verification in the system installation path; 3) This application can complete the selection / generation of targeted security domains and the binding of process security contexts during the application startup period, and inject policy fragments consistent with PEP into the kernel SELinux, so that permission changes only apply to the application runtime. 4) This application achieves rapid customization and revocation through secure storage and revocation / expiration mechanisms, and the isolation of privilege escalation records for different applications can reduce the lateral impact on other applications in the system; 5) This application supports an operational process of "development application - platform review - market release - automatic activation on the client side" in the ToB delivery model, taking into account both agility and security audit requirements. Attached Figure Description

[0016] The preferred embodiments will now be described in a clear and easy-to-understand manner, with reference to the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of this solution.

[0017] Figure 1 This is a schematic diagram of the overall process of one embodiment of the present invention; Figure 2 This is a schematic diagram of the system framework of one embodiment of the present invention; Figure 3 This is a schematic diagram of the application feature extraction and privilege escalation configuration package generation process according to an embodiment of the present invention; Figure 4 This is a schematic diagram of target application delivery and end-side reception according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the application installation phase parsing, designing, and verification process according to an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the targeted security domain generation, process binding, and policy injection of an embodiment of the present invention. Detailed Implementation

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0019] To keep the drawings concise, only the parts relevant to the invention are shown schematically in each figure, and they do not represent the actual structure of the product. Furthermore, for ease of understanding, in some figures, only one of components with the same structure or function is shown schematically, or only one is labeled. In this document, "one" can mean not only "only one" but also "more than one".

[0020] In ToB smart hardware and industry-customized scenarios, the Android public version system typically employs a relatively strict SELinux policy to ensure baseline system security. Customer business applications (APKs) are mostly retrofitted applications, and their functions often require access to sensitive resources restricted by default policies. If general domain permissions such as untrusted_app are directly relaxed in the public version policy, the expanded permissions will affect all similar applications, leading to a significant increase in the overall system attack surface. On the other hand, customer application requirements are diverse and iterate frequently. Adopting a strategy of maintaining an independent ROM for each customer or implementing full-device OTA updates would result in ROM fragmentation and high delivery costs. Relying solely on application-level permissions (non-SELinux domain capabilities) often fails to meet the access requirements of underlying resources. Therefore, a technical solution is needed that can selectively grant additional SELinux capabilities to specific customer applications within their installed and running scope.

[0021] This solution extracts verifiable features from the customer's application APK and cryptographically binds them to the privilege escalation configuration. During installation / update via controlled channels, a signed privilege escalation package is simultaneously distributed. After offline / online verification on the client side, a targeted security domain is established for the application, and process binding and policy injection are completed during startup. This ensures that privilege escalation only applies to the application's runtime and does not extend to other similar applications, achieving "targeted, verifiable, and auditable" SELinux capability extension for the customer's application on a public system. The following is a detailed description of this solution with reference to the accompanying diagrams: In one embodiment, refer to the appendix to the specification. Figure 1 This application provides an application-oriented security strategy injection generation method, applied to a terminal device, comprising: S100. Obtain the installation package information corresponding to the target application sent from the cloud. The installation package information includes at least the application package, the application signature obtained by parsing the application package from the cloud, the privilege escalation configuration package generated by the cloud based on the permission request information of the target application, and the binding signature generated by the cloud by combining the application signature and the privilege escalation configuration package and signing it with a private key.

[0022] S200. During the installation phase of the target application, the application signature and binding signature are used to verify whether the target application is an application to be privileged. After the verification is passed, a targeted authorization status is written to the target application. The targeted authorization status includes at least setting the feature flag, recording the targeted security domain template identifier to be used, the policy fragment version number, and the hash of the allowed permission increment set.

[0023] S300: When creating the application process during the target application startup phase, read the targeted authorization status and select or generate a targeted security domain for the target application; at the same time, switch the security context of the application process to the area corresponding to the targeted security domain, and merge the permission increment corresponding to the policy fragment into the kernel policy graph, so that the target application runs in the targeted security domain with the target permissions.

[0024] For details, please refer to the attached instruction manual. Figure 2 The overall framework of this solution includes: a cloud-based signing and configuration subsystem, a controlled application distribution channel (application marketplace / enterprise delivery platform), an installation verification subsystem within the terminal operating system, a secure storage subsystem, an application startup orchestration subsystem, and a kernel SELinux policy injection subsystem.

[0025] Reference manual attached Figure 3 The cloud platform is responsible for feature extraction, privilege escalation strategy review, privilege escalation configuration package generation, and signature binding. Customers submit their APKs to the platform for release. The cloud parses the APK to obtain the Application Feature Code (AFC, a set of identity features consisting of the application package name, signing certificate fingerprint, APK or key binary integrity digest, etc., used to bind the privilege escalation configuration to a specific installed application instance; also known as an application fingerprint). The application feature code includes at least the application package name, application signing certificate chain fingerprint, application package file digest, or integrity fingerprint of key SO / resource segments.

[0026] Simultaneously, the cloud will generate a privilege escalation configuration package (PEP) based on the target application's permission request information. The PEP is a structured data packet describing the scope of SELinux permissions granted to a customer application, applicable conditions, policy template version, and metadata. It is distributed after being signed with the platform's private key and can also be called a privilege escalation package. The PEP includes at least the requested targeted security domain template identifier, policy fragment version number, permission increment set, policy validity period, channel identifier of the controlled distribution channel, and the customer identifier of the target application. In other words, the platform converts the customer's requested "scope of SELinux capabilities to be escalated" into a structured privilege escalation configuration package (PEP), expressed for example, as a policy template identifier + parameterized allowed list (involving equivalent descriptions of type / class / perm or macro expansions), applicable minimum version, validity period, channel identifier, and tenant / customer identifier.

[0027] Furthermore, to enable the platform to extract verifiable features and cryptographically bind them to privilege escalation configurations, this solution combines the application signature and privilege escalation configuration package and generates a binding signature (BS, a digital signature that cryptographically binds the application signature digest, PEP content digest, validity period, distribution channel identifier, device or tenant identifier (optional), etc., for tamper-proofing and replay protection; also known as an associated signature). The binding signature must include at least the application package file digest, privilege escalation configuration package digest, policy validity period, channel identifier, customer identifier, and a random number generated by the private key signature. For example, signing fields such as "AFC digest / PEP digest / validity period / channel / tenant information / random number nonce" strongly binds the PEP to a specific application identity and publishing context. The signing key can be stored in the HSM / KMS, and the platform records the audit log (applicant, rule diff, approver, publication time, revocation status) to meet compliance audit requirements.

[0028] The channel is responsible for distributing the APK and PEP within a unified installation transaction or associated session. Preferably, when obtaining the installation package information corresponding to the target application distributed from the cloud, this includes: obtaining the installation package information through a controlled distribution channel based on the privilege escalation configuration package payload attached in the installation session, or based on the accompanying file with the same version number as the target application, or based on the privilege escalation configuration package byte stream submitted by the market client when calling the system privileged installation interface.

[0029] Reference manual attached Figure 4 Controlled distribution channels (CDCs) deliver the APK along with its corresponding PEP (Platform Execution Protocol) when a user installs or updates an application. This can be achieved through methods including, but not limited to: attaching the PEP payload to the installation session, using a companion file with the same version number as the APK (companion artifact), or having the market client call the system's privileged installation interface to simultaneously submit the PEP byte stream. A controlled distribution channel (CDC) is an application marketplace, enterprise MDM (Made for Demand) platform, or industry delivery platform that, after being audited by the platform vendor, can simultaneously distribute and verify the PEP during application installation or updates; it can also be referred to as an application marketplace.

[0030] A further preferred embodiment of the application-oriented security policy generation and injection method provided in this application includes: secondary encryption of the privilege escalation configuration packet using a device-unique key or a session key of the installation session. Specifically, the transport layer employs TLS and certificate locking; the PEP can be secondary encrypted, and the key is protected by a device-unique key or session negotiation.

[0031] After verifying whether the target application is the application to be privileged by applying the feature code and binding the signature, the process also includes: writing the privilege escalation configuration package data and policy index corresponding to the verified target application into the protected storage area, and establishing a connection and record with fields containing the application package name, customer identifier, privilege escalation configuration package version, policy validity period, and revocation token; the privilege escalation configuration package data corresponding to the verified target application shall not be written into the policy effective path.

[0032] The verified PEP metadata and policy index are written to a protected storage area (such as an encrypted directory or key storage domain accessible only to system services), and a record is created with fields such as package name, installation source, PEP version, expiration time, and revocation token. PEPs that fail verification must not be written to the policy's effective path to prevent them from being read or tampered with by third-party applications.

[0033] The terminal completes the designing and policy metadata write-to-disk process at the system service layer. In one specific implementation, the verification of whether the target application is the application to be privileged is performed by using the application's signature and bound signature, including: Verify the binding signature and compare the application signature with the actual characteristics of the installed target application, including application package name consistency comparison, application signature certificate chain fingerprint consistency comparison, and application package file digest consistency comparison. If the verification passes, the target application is determined to be an application to be privileged.

[0034] Reference manual attached Figure 5 Before the application installation is complete, the terminal device can use privileged components (such as the package_manager_service extension module and dedicated installer service) to parse the PEP, verify the platform certificate chain, bind the signature BS, PEP signature, validity period and device time policy; at the same time, the AFC declared by the PEP is compared with the actual characteristics of the installed APK (package name, signature fingerprint, digest are consistent), and the target application is determined to be the application to be privileged.

[0035] Preferably, the application-oriented security policy generation and injection method provided in this application further includes: when network conditions are available, performing supplementary online verification, including querying the platform's revocation list, verifying whether the policy version is still allowed to be issued, and whether it is synchronized with the server time / lease; in offline scenarios, performing downgrade verification based on the local certificate chain and signature timestamp policy, and performing supplementary online verification when network conditions are met subsequently.

[0036] When network conditions are available, online supplementary verification can be performed to check the platform's revocation list, verify whether the policy version is still allowed to be issued, and synchronize with the server time / lease. In offline scenarios, downgrade verification is performed based on the local certificate chain and signature timestamp policy, and online verification is performed again when network conditions are met later. Online supplementary verification (OVC) is used to perform online verification of PEP or policy versions when network conditions are available on the client side, such as revocation list query, policy version allowable set verification, and validity period alignment with server time.

[0037] If the verification passes, the system writes a targeted authorization status to the application, such as setting a feature flag, recording the targeted security domain template identifier to be used, the policy fragment version number, and the hash of the allowed permission increment set. If the verification fails, the PEP is denied and a security log is logged.

[0038] A Directed Security Domain (DSD) is an SELinux domain assigned or selected for a verified client application process. It is isolated from the default non-system application domain, ensuring that permission changes only affect the application at runtime. Policy Fragments (SPs) are subsets of rules that can be incorporated into the kernel's SELinux policy, such as a set of allow rules for a specific type, used to enforce PEP-authorized access capabilities within a directed security domain.

[0039] This solution completes the selection of a targeted security domain and process binding during the application startup phase, and submits or activates the corresponding policy fragment to the kernel. This enables the application process to bind its security context to the targeted security domain before it is created or enters the executable phase, and to complete the verification or loading of consistency with the policy fragment.

[0040] Preferably, reading the targeted authorization status and selecting or generating a targeted security domain for the target application includes: The system reads the directed authorization status to determine if valid privilege escalation configuration package information exists. If yes, based on the preset policy slots and parameterization types, it maps information including the application package name, application signing certificate chain fingerprint, and UID range to the selected directed security domain in the application security context configuration; or it dynamically distributes or updates the patch file trusted by the application security context configuration during application startup and triggers policy reloading to generate a directed security domain for the target application to run; or it compiles the privilege escalation configuration package information into a small policy fragment and merges it with the baseline policy, then injects it through the policy loading interface supported by the kernel to generate a directed security domain for the target application to run; if no, the system uses the normal application startup process.

[0041] For details, please refer to the attached instruction manual. Figure 6When an application process is created, the system intercepts the startup path before the zygote-derived child process: reads the targeted authorization status of the package; if a valid PEP exists, it selects or generates a targeted security domain for the application instance. Implementation methods include, but are not limited to: mapping "package name + signature fingerprint + UID range" to the DSD in the seapapp_contexts mapping based on pre-defined policy slots and parameterized types (e.g., assigning an independent type name or type alias to each client / application); dynamically issuing / updating a trusted seapapp_contexts patch file during startup and triggering policy reloading; compiling the PEP into a mini policy fragment SP and merging it with the baseline policy before injecting it through a kernel-supported policy loading interface.

[0042] During the process binding phase, before and after setuid / setgid is completed, the process security context is switched to the area corresponding to the DSD through setcon or an equivalent mechanism, so that subsequent access control decisions fall on the set of directed rules.

[0043] The policy injection extreme approach merges allow / avtab rules from the Service Provider (SP) into the kernel policy graph, ensuring that only the DSD can gain new capabilities without modifying the default policies of other application domains. If a "slot-based type" approach is adopted, the SP can degenerate into simply filling allow rules into slot types, reducing runtime compilation complexity.

[0044] During application runtime, its processes remain within a targeted security domain. When an application is uninstalled, its PEP expires, it is revoked by the administrator, or the market rolls back its configuration, the system clears the targeted authorization status and triggers policy invalidation. Users can choose not to bind to DSD on the next startup, or execute a controlled restart policy for already running processes. Privilege escalation records for different applications are isolated and do not affect each other.

[0045] This solution enables targeted, verifiable, and auditable SELinux capability extensions for customer applications on public systems: privilege escalation only applies to the runtime of verified target applications by default; configurations can be released by application developers after platform review and rapidly iterated through the application marketplace; privilege escalations for different customer applications are isolated from each other. Compared to directly relaxing permissions in general application domains, this solution limits the security impact to targeted security domains, which helps maintain the overall baseline security of the system; compared to ROM-level merging, this solution significantly shortens the policy change chain and reduces the risk of image splitting.

[0046] In one embodiment, this application also provides an application-oriented security policy generation and injection system, including: a client, a remote end, and a terminal device; the client sends a target application to be published to the cloud; the terminal device obtains installation package information corresponding to the target application from the cloud, the installation package information including at least an application package, an application signature obtained by the cloud from parsing the application package, an escalation configuration package generated by the cloud based on the permission request information of the target application, and a binding signature generated by the cloud by combining the application signature and the escalation configuration package and performing private key signing.

[0047] During the installation phase of the target application, the terminal device verifies whether the target application is an application to be privileged and elevated by using the application feature code and binding signature. After the verification is passed, a targeted authorization status is written to the target application. The targeted authorization status includes at least setting the feature flag, recording the targeted security domain template identifier to be used, the policy fragment version number, and the hash of the allowed permission increment set.

[0048] When the terminal device creates the application process during the target application startup phase, it reads the targeted authorization status and selects or generates a targeted security domain for the target application. At the same time, it switches the security context of the application process to the area corresponding to the targeted security domain and merges the permission increment corresponding to the policy fragment into the kernel policy graph, so that the target application runs in the targeted security domain with the target permissions.

[0049] The technical concept of the application-oriented security policy generation injection system provided in this embodiment is the same as that of the application-oriented security policy generation injection method in the aforementioned embodiments, and will not be described again here.

[0050] In one embodiment, this application provides a terminal device including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the application-oriented security policy generation injection method of the foregoing embodiments.

[0051] The application-oriented security strategy generation injection method, system, and terminal device provided by this invention have at least the following technical effects: 1) This application binds the application feature code (package name, signature fingerprint, binary / file digest, etc.) obtained by APK parsing to the PEP content for signature, so that the privilege escalation configuration is strongly bound to the specific application installation instance. Unlike the relaxed whole-device policy without identity constraints, it will not extend the privilege to other similar applications and avoid causing security risks. 2) This application can distribute PEPs synchronously during application installation / update through a controlled distribution channel, and complete the closed loop of unsigning, validity period and feature consistency verification and optional online supplementary verification in the system installation path; 3) This application can complete the selection / generation of targeted security domains and the binding of process security contexts during the application startup period, and inject policy fragments consistent with PEP into the kernel SELinux, so that permission changes only apply to the application runtime. 4) This application achieves rapid customization and revocation through secure storage and revocation / expiration mechanisms, and the isolation of privilege escalation records for different applications can reduce the lateral impact on other applications in the system; 5) This application supports an operational process of "development application - platform review - market release - automatic activation on the client side" in the ToB delivery model, taking into account both agility and security audit requirements.

[0052] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for generating injection using a targeted security strategy, applied to a terminal device, characterized in that, include: Obtain the installation package information corresponding to the target application sent from the cloud. The installation package information includes at least the application package, the application feature code obtained by the cloud from parsing the application package, the privilege escalation configuration package generated by the cloud based on the permission request information of the target application, and the binding signature generated by the cloud by combining the application feature code and the privilege escalation configuration package and performing private key signing. During the installation phase of the target application, the application feature code and the binding signature are used to verify whether the target application is an application to be privileged. After the verification is passed, a targeted authorization status is written to the target application. The targeted authorization status includes at least setting a feature flag, recording the targeted security domain template identifier to be used, the policy fragment version number, and the hash of the allowed permission increment set. During the application process creation phase of the target application startup, the targeted authorization status is read, and a targeted security domain is selected or generated for the target application. At the same time, the security context of the application process is switched to the region corresponding to the targeted security domain, and the permission increment corresponding to the policy fragment is merged into the kernel policy graph, so that the target application runs in the targeted security domain with the target permissions.

2. The application-oriented security strategy generation injection method according to claim 1, characterized in that, The application signature code includes at least the application package name, the application signature certificate chain fingerprint, and the application package file digest; The privilege escalation configuration package includes at least the following structured information: a requested targeted security domain template identifier, a policy fragment version number, a set of permission increments, a policy validity period, a channel identifier for the controlled distribution channel, and a customer identifier for the target application. The fields of the binding signature include at least the application package file digest, privilege escalation configuration package digest, policy validity period, channel identifier, customer identifier, and a random number generated by the private key signature.

3. The application-oriented security strategy injection method according to claim 1, characterized in that, When retrieving the installation package information corresponding to the target application from the cloud, the following should be included: The installation package information is obtained through a controlled distribution channel based on the privilege escalation configuration package payload attached in the installation session, or based on the accompanying file with the same version number as the target application, or based on the privilege escalation configuration package byte stream submitted by the market client when calling the system privileged installation interface.

4. The application-oriented security strategy injection method according to claim 3, characterized in that, Also includes: The privilege escalation configuration package is then encrypted a second time using the device's unique key or the session key of the installation session.

5. The application-oriented security strategy injection method according to claim 2, characterized in that, Verification of whether the target application is an application to be privileged is performed using the application feature code and the binding signature, including: Verify the binding signature and compare the application feature code with the actual characteristics of the installed target application, including application package name consistency comparison, application signature certificate chain fingerprint consistency comparison, and application package file digest consistency comparison. If the verification passes, determine that the target application is an application to be privileged.

6. The application-oriented security strategy injection method according to claim 2, characterized in that, Reading the targeted authorization status and selecting or generating a targeted security domain for the target application includes: Read the directed authorization status to determine whether there is a valid privilege escalation configuration package information; If the determination is yes, then based on the preset policy slot and parameterization type, the information including the application package name, application signing certificate chain fingerprint, and UID range in the application security context configuration is mapped to the selected targeted security domain; or during application startup, a patch file trusted by the application security context configuration is dynamically issued or updated and policy reloading is triggered to generate the targeted security domain for the target application to run; or the privilege escalation configuration package information is compiled into a small policy fragment and merged with the baseline policy and injected through the policy loading interface supported by the kernel to generate the targeted security domain for the target application to run. If the result is negative, the standard application startup process will be used.

7. The application-oriented security strategy generation injection method according to claim 5, characterized in that, Also includes: When network conditions are available, perform supplementary online verification, including checking the platform's revocation list, verifying whether the policy version is still allowed to be issued, and checking whether the time / lease is synchronized with the server. In offline scenarios, downgrade verification is performed based on the local certificate chain and signature timestamp strategy, and online verification is performed when network conditions are met later.

8. The application-oriented security strategy generation injection method according to any one of claims 1-7, characterized in that, After verifying whether the target application is the application to be privileged by using the application signature and the binding signature, the method further includes: The privilege escalation configuration package data and policy index corresponding to the target application that pass the verification are written to the protected storage area, and a connection is established and recorded with fields including application package name, customer identifier, privilege escalation configuration package version, policy validity period, and revocation token; the privilege escalation configuration package data corresponding to the target application that fails the verification shall not be written to the policy effective path.

9. A system for generating injections using a targeted security strategy, characterized in that, include: Client, remote, and terminal devices; The client sends the target application to be published to the cloud. The terminal device obtains installation package information corresponding to the target application from the cloud. The installation package information includes at least an application package, an application feature code obtained by the cloud from parsing the application package, an privilege escalation configuration package generated by the cloud based on the permission request information of the target application, and a binding signature generated by the cloud by combining the application feature code and the privilege escalation configuration package and performing private key signing. During the installation phase of the target application, the terminal device verifies whether the target application is an application to be privileged and elevated by using the application feature code and the binding signature. After the verification is passed, the terminal device writes a targeted authorization status to the target application. The targeted authorization status includes at least setting a feature flag, recording the targeted security domain template identifier to be used, the policy fragment version number, and the hash of the allowed permission increment set. When the terminal device creates the application process during the startup phase of the target application, it reads the targeted authorization status and selects or generates a targeted security domain for the target application. At the same time, it switches the security context of the application process to the region corresponding to the targeted security domain and merges the permission increment corresponding to the policy fragment into the kernel policy graph, so that the target application runs in the targeted security domain with the target permissions.

10. A terminal device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the application-oriented security policy generation injection method according to any one of claims 1-8.

Images