Secure running method and apparatus for application program, device, and storage medium

Abstract

The present application relates to a secure running method and apparatus for an application program, a device, and a storage medium. The method comprises: acquiring a current user instruction for a current application program, and parsing the current user instruction to obtain first metadata of the current user instruction (S201); on the basis of the first metadata, determining an instruction type of the current user instruction (S202); when the instruction type is a main instruction type, determining a first security verification result (S203); when the first security verification result indicates that the verification is passed, acquiring from the first metadata a subordinate sub-instruction of the current user instruction (S204); when it is determined that the subordinate sub-instruction is an executable instruction, determining a second security verification result (S205); and when the second security verification result indicates that the verification is passed, executing the subordinate sub-instruction to obtain an execution result of the current user instruction (S206).

Description

A method, apparatus, device, and storage medium for secure operation of an application.

[0001] Related applications

[0002] This application claims priority to Chinese patent application No. 2024117924161, filed on December 7, 2024, entitled "A method, apparatus, device and storage medium for secure operation of an application", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer security operation technology, and in particular to a method, apparatus, device, storage medium and computer program product for secure operation of an application. Background Technology

[0004] Linux is an open-source operating system widely used in various devices due to its stability, security, and efficiency. The command processing system is the core of Linux, responsible for receiving user input, executing corresponding operations, and returning results.

[0005] In traditional Linux environments, polymorphic binary technology is often used to reduce file system footprint by executing multiple functions through a single executable binary. For example, BusyBox is a widely used polymorphic binary application that integrates a large number of commonly used UNIX commands and tools.

[0006] However, this integration method typically limits fine-grained permission control over individual commands. Each command can only run with the same permissions, and permission settings cannot be adjusted according to different use cases. It also has many limitations such as poor security and poor flexibility when executing commands. Summary of the Invention

[0007] According to various embodiments of this application, a method, apparatus, device, storage medium, and computer program product for secure operation of an application are provided.

[0008] In a first aspect, this application provides a method for securely running an application, the method comprising:

[0009] Obtain the current user instruction for the current application, parse the current user instruction, and obtain the first metadata of the current user instruction;

[0010] The instruction type of the current user instruction is determined based on the first metadata;

[0011] When the instruction type is the primary instruction type, the first execution permission of the current user instruction is verified based on the first security configuration file to obtain the first security verification result.

[0012] When the first security verification result is successful, the next-level sub-instruction of the current user instruction is obtained from the first metadata;

[0013] When it is determined that the lower-level sub-instruction is an executable instruction, a security verification is performed on the second execution permission of the lower-level sub-instruction based on the second security configuration file, and a second security verification result is obtained; and

[0014] When the second security verification result is successful, the lower-level sub-instruction is executed to obtain the execution result of the current user instruction.

[0015] In one embodiment, the security verification of the first execution permission of the current user instruction based on the first security configuration file to obtain a first security verification result includes:

[0016] Obtain the first security configuration file corresponding to the current user instruction; the first security configuration file is obtained by configuring the first execution permission for the main instruction type of the current application; and

[0017] The first execution permission of the current user's instruction is verified according to the first security configuration file to obtain the first security verification result.

[0018] In one embodiment, before obtaining the first security configuration file corresponding to the current user instruction, the method further includes:

[0019] Obtain the first user list of the current application and the first execution permissions corresponding to the main instruction type for each first user account in the first user list; the first execution permissions include at least one of the following: first execution trigger permission, first execution time window permission, first execution frequency permission, and first concurrent execution permission for the first user account for instructions belonging to the main instruction type; and

[0020] Based on the first execution permissions of each of the first user accounts, configure the first security configuration file corresponding to the first user account.

[0021] In one embodiment, the security verification of the second execution permission of the lower-level sub-instruction based on the second security configuration file to obtain a second security verification result includes:

[0022] Obtain the second security configuration file corresponding to the lower-level sub-instruction; the second security configuration file is obtained by configuring the second execution permission for the sub-instruction type of the current application; and

[0023] The second execution permission of the lower-level sub-instruction is verified according to the second security configuration file to obtain the second security verification result.

[0024] In one embodiment, before obtaining the second security configuration file corresponding to the lower-level sub-instruction, the method further includes:

[0025] Obtain the second user list of the current application and the second execution permissions corresponding to the sub-instruction types of each second user account in the second user list; the second execution permissions include at least one of the following: second execution trigger permission, second execution time window permission, second execution frequency permission, and second concurrent execution permission for the second user account regarding instructions belonging to the sub-instruction type; and

[0026] Based on the second execution permissions of each of the second user accounts, configure the second security configuration file corresponding to the second user account.

[0027] In one embodiment, the method further includes at least one of the following:

[0028] When the first security verification result is a verification failure, the execution of the current user instruction is rejected and a first exception log is recorded; and

[0029] When the second security verification result is that the verification fails, the execution of the lower-level sub-instruction is rejected and a second exception log is recorded.

[0030] In one embodiment, the method further includes at least one of the following:

[0031] When the instruction type is a sub-instruction type and the current user instruction belongs to the executable instruction, the second execution permission of the current user instruction is security verified based on the second security configuration file to obtain a third security verification result; when the third security verification result is successful, the current user instruction is executed to obtain the execution result of the current user instruction; and

[0032] When the instruction type is a sub-instruction type and the current user instruction does not belong to the executable instruction, or the lower-level sub-instruction does not belong to the executable instruction, an alarm is triggered for the current user instruction and a third abnormal log is recorded.

[0033] Secondly, this application also provides a secure operation device for an application, the device comprising:

[0034] The instruction parsing module is used to obtain the current user instruction for the current application, parse the current user instruction, and obtain the first metadata of the current user instruction;

[0035] The instruction type determination module is used to determine the instruction type of the current user instruction based on the first metadata.

[0036] The first verification module is used to perform security verification on the first execution permission of the current user instruction based on the first security configuration file when the instruction type is the main instruction type, and obtain the first security verification result.

[0037] The lower-level instruction acquisition module is used to acquire the lower-level sub-instruction of the current user instruction from the first metadata when the first security verification result is verification passed.

[0038] The second verification module is used to perform security verification on the second execution permission of the lower-level sub-instruction based on the second security configuration file when it is determined that the lower-level sub-instruction is an executable instruction, and obtain a second security verification result; and

[0039] The instruction execution module is used to execute the lower-level sub-instruction when the second security verification result is successful, and obtain the execution result of the current user instruction.

[0040] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0041] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0042] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0043] Details of one or more embodiments of this application are set forth in the following drawings and description. Other features, objects, and advantages of this application will become apparent from the specification, drawings, and claims. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the disclosed drawings without creative effort.

[0045] Figure 1 is an application environment diagram of the secure operation method of the application in some embodiments;

[0046] Figure 2 is a flowchart illustrating the secure operation method of an application in some embodiments;

[0047] Figure 3 is a system block diagram of a method for executing secure application execution in some application examples;

[0048] Figure 4 shows the command security execution control flowchart in some application examples;

[0049] Figure 5 shows the overall flowcharts for some application examples;

[0050] Figure 6 is a structural block diagram of the secure operation device for applications in some embodiments;

[0051] Figure 7 is an internal structure diagram of a computer device in some embodiments. Detailed Implementation

[0052] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0053] The secure operation method for an application provided in this application embodiment can be applied to the application environment shown in Figure 1. Terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed on a cloud or other network server. Server 104 obtains and parses the current user instruction sent by terminal 102 for the current application, and can obtain the first metadata in the current user instruction to determine the instruction type. Based on the instruction type, server 104 selects a first security profile to perform security verification on the current user instruction. After successful security verification, server 104 extracts the lower-level sub-instructions of the current user instruction from the first metadata and determines whether the lower-level sub-instructions are executable. If the lower-level sub-instructions are executable, server 104 selects a second security profile to perform security verification on the lower-level sub-instructions. After successful security verification, server 104 executes the lower-level sub-instructions, ensuring that each instruction can only be executed under conditions that comply with a preset security policy, thereby improving the security of the current application operation.

[0054] The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle systems, and projection equipment. Portable wearable devices can include smartwatches and smart bracelets. The server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0055] In an exemplary embodiment, as shown in FIG2, a method for securely running an application is provided, illustrated using the method applied to server 104 in FIG1 as an example; it is understood that the method can also be applied to terminal 102 in FIG1, and can also be applied to a system including server 104 and terminal 102, implemented through the interaction between server 104 and terminal 102. The method of this embodiment includes:

[0056] Step S201: Obtain the current user instruction for the current application, parse the current user instruction, and obtain the first metadata of the current user instruction.

[0057] Here, the current application refers to the software program or system running on the server, used to enable interaction between the client and the server. The client can be a device or other application capable of triggering commands. In an optional embodiment, the current application further refers to an application based on a business completion polymorphic binary.

[0058] The current user instruction refers to the instruction being processed by the current application. This instruction can be a clicked button, a entered command, a selected option, etc., used to instruct the current application to perform a specific operation or function. The current user instruction is usually contained within the user request. By listening to, reading, and parsing the data in the user request, the server can identify the specific operation the user wishes to perform and extract the current user instruction.

[0059] Parsing the current user instruction refers to the process by which the server decomposes the current user instruction on the current application to obtain the more basic elements carried in the current user instruction, such as instruction identifiers and parameters, so that the server can identify the specific operation that the user wants to perform.

[0060] The first metadata refers to the data associated with the current user instruction. The first metadata includes, but is not limited to, the instruction identifier, instruction type, priority, operation object, operation parameters, and other information of the current user instruction, so that the server can process and understand the current user instruction.

[0061] For example, the server listens for user requests from the current application in real time. When a user request is received, the server reads and parses the various data carried in the user request to extract the current user instruction from the data. Subsequently, the server parses the current user instruction according to a predefined format or protocol, and identifies and extracts information related to primary metadata such as instruction identifier, instruction type, priority, operation object, and operation parameters from the current user instruction.

[0062] During parsing, the server can use predefined formats or protocols to parse the current user's instructions. Predefined formats include, but are not limited to, XML (eXtensible Markup Language), JSON (JavaScript Object Notation), CSV (Comma-Separated Values), etc. Parsing protocols include, but are not limited to, HTTP (Hypertext Transfer Protocol) and TCP / IP (Transmission Control Protocol / Internet Protocol).

[0063] Step S202: Determine the instruction type of the current user instruction based on the first metadata.

[0064] Instruction type refers to the category or classification of the current user instruction. Different instruction types correspond to different processing logic and permission requirements. In this embodiment, instruction types mainly include main instruction type and sub-instruction type. The main instruction type corresponds to the main instruction, which can be used to call a function, execute a specific task, or start or specify an operation or function. The sub-instruction type corresponds to sub-instructions, which are appended to the main instruction to provide more detailed or specific operations. Sub-instructions can usually be used to modify the behavior or parameters of the main instruction, or to execute additional tasks related to the main instruction. A main instruction can have one or more sub-instructions to refine or expand the functionality of the main instruction.

[0065] For example, the server determines the instruction type of the current user instruction based on at least one of the instruction identifier, instruction type, priority, operation object, and operation parameters of the current user instruction contained in the first metadata.

[0066] Step S203: When the instruction type is the primary instruction type, perform security verification on the first execution permission of the current user instruction based on the first security configuration file to obtain the first security verification result.

[0067] The primary instruction type refers to the instruction type that has higher priority or greater importance during the current application's execution.

[0068] The first security configuration file is used to verify the first execution permission of the current user's instructions. It defines the information that different clients are authorized to execute specific types of instructions, and the specific operations these instructions can perform. First execution permission refers to the permission of different clients to execute the current user's instructions. The first security verification result is the result obtained after verifying the first execution permission of the current user's instructions according to the first security configuration file. The first security verification result indicates whether the security verification of the current user's instructions has passed; passing means the client has permission to execute the current user's instructions, while failing means the client does not have permission to execute the current user's instructions.

[0069] For example, when the instruction type of the current user instruction is determined to be the primary instruction type, the server performs a security verification on the first execution permission of the current user instruction based on the first security configuration file to determine whether the client has execution permission for the current user instruction of the current application, and thus obtains the first security verification result.

[0070] In addition, when performing security verification on the first execution permission, the server can also log the verification process to facilitate tracking and recording of the verification status of the command, and to facilitate analysis of the verification status afterward.

[0071] Step S204: When the first security verification result is successful, obtain the next-level sub-instruction of the current user instruction from the first metadata.

[0072] Among them, a lower-level sub-instruction refers to a lower-level instruction or an instruction with more detailed operation that is contained in or related to the current user instruction. The lower-level sub-instruction is carried in the first metadata as a component of the current instruction.

[0073] For example, when the first security verification result of the first execution permission of the current user instruction is successful, the server obtains the lower-level sub-instruction of the current user instruction from the first metadata.

[0074] Step S205: When it is determined that the lower-level sub-instruction is an executable instruction, the second execution permission of the lower-level sub-instruction is verified based on the second security configuration file to obtain the second security verification result.

[0075] Among them, executable instructions refer to instructions that have been recognized by the server as valid and executable.

[0076] The second security configuration file is used to verify the second execution permissions of subordinate sub-instructions. Similar to the first security configuration file, the second security configuration file defines the information about the type of instructions that different clients are authorized to execute, and the specific operations these instructions can perform. Second execution permissions refer to the permissions of different clients to execute subordinate sub-instructions. The second security verification result is the result obtained after verifying the second execution permissions of subordinate sub-instructions according to the second security configuration file. The second security verification result indicates whether the security verification of the subordinate sub-instruction has passed; passing means the client has permission to execute the subordinate sub-instruction, while failing means the client does not have permission to execute the subordinate sub-instruction.

[0077] For example, when it is determined that the lower-level sub-instruction is an executable instruction, the server performs a security verification on the second execution permission of the lower-level sub-instruction based on the second security configuration file, in order to determine whether the client has execution permission for the lower-level sub-instruction of the current application, and thus obtains the second security verification result.

[0078] In addition, when performing security verification on the second execution permission, the server can also log the verification process to facilitate the tracking and recording of the verification status of the instructions, and to facilitate the analysis of the verification status afterward.

[0079] Step S206: When the second security verification result is successful, execute the next-level sub-instruction to obtain the execution result of the current user instruction.

[0080] Executing a subordinate sub-instruction refers to the process by which the server executes the subordinate sub-instruction to run the current application after the instruction has passed the necessary authorization verification. The execution result of the current user instruction refers to the result obtained after executing the subordinate sub-instruction, that is, the running result of the current application.

[0081] For example, when the second security verification result of the second execution permission of the subordinate sub-instruction is passed, the server executes the subordinate sub-instruction to obtain the execution result of the current user instruction, thereby enabling the current application to run securely under the action of the current user instruction and its subordinate sub-instructions.

[0082] When executing a lower-level sub-instruction, the server may, but is not limited to, call and parse the lower-level sub-instruction from its instruction entry point to obtain the second metadata of the lower-level sub-instruction, and then execute the lower-level sub-instruction based on the second metadata.

[0083] In addition, after the server executes the lower-level sub-instruction, the execution information of the lower-level sub-instruction can be logged. The execution information includes the execution time, the specific operation performed, and the execution result, so as to facilitate the tracking and recording of the system's operation and facilitate the analysis of the execution situation afterward.

[0084] In the aforementioned secure operation method for the application, when a client initiates a user request for the current application, the server parses the current user instruction from the user request. By obtaining the current user instruction for the current application, parsing the current user instruction, and obtaining the first metadata of the current user instruction, the server can determine the instruction type of the current user instruction from the first metadata. When the server determines that the instruction type of the current user instruction is the primary instruction type, it performs a security verification on the first execution permission of the current user instruction based on the first security configuration file, obtaining a first security verification result to ensure that the execution of the current user instruction complies with the secure operation policy. Subsequently, when the first security verification result is successful, the server obtains the current user instruction's execution permission from the first metadata. When the server determines that a sub-instruction of a previous user instruction is executable, it performs a security verification on the second execution permission of the sub-instruction based on a second security configuration file. This verification result ensures that the execution of the sub-instruction complies with the security operation policy. If the second security verification passes, the sub-instruction is executed, and the execution result of the current user instruction is obtained. By using corresponding security configuration files to perform security verification on execution permissions for different types and user instructions, more granular permission control can be achieved. Furthermore, dynamically adjusting the permission settings of different instructions using security configuration files allows for rapid adaptation to constantly changing business and security needs, effectively preventing unauthorized access and operations.

[0085] In one embodiment, a security verification is performed on the first execution permission of the current user's instruction based on a first security configuration file to obtain a first security verification result, including:

[0086] Obtain the first security configuration file corresponding to the current user command; verify the first execution permission of the current user command based on the first security configuration file, and obtain the first security verification result.

[0087] The first security configuration file is configured with the first execution permission for the main instruction type of the current application. Specifically, the first security configuration file is pre-generated and stored in the server's data storage system. The first security configuration file defines in detail the various permissions for the instructions corresponding to the main instruction type when they are executed, and is used to determine whether the execution of the instructions corresponding to the main instruction type complies with the preset security policy.

[0088] For example, the server retrieves the first security configuration file corresponding to the current user instruction from the data storage system; and performs detailed verification of the first execution permission of the current user instruction based on the first security configuration file to obtain the first security verification result.

[0089] In this embodiment, the server obtains the first security configuration file corresponding to the current user instruction and verifies the first execution permission of the current user instruction according to the first security configuration file. This allows the server to obtain the first security verification result corresponding to the first execution permission. The server can then perform matching verification on the current user instruction before execution, ensuring that the execution of all current user instructions complies with the preset security policy, thereby improving the security of system operation.

[0090] In one embodiment, before obtaining the first security configuration file corresponding to the current user instruction, the method further includes:

[0091] Obtain the first user list of the current application and the first execution permission of the first user account in the first user list corresponding to the main instruction type; based on the first execution permission of the first user account, configure the first security configuration file corresponding to the first user account.

[0092] The first user list refers to the list of user information that has been registered or authorized in the current application. This first user list includes each user's first user account and the first execution permission of each user account corresponding to the main instruction type. The first user account is a unique identifier for the user and can be a username, user ID, or other information that can distinguish different users. The first user list can be pre-stored in a data storage system or obtained from an external device during configuration.

[0093] The first execution permission includes at least one of the following: the first user account's first execution trigger permission for instructions belonging to the main instruction type, the first execution time window permission, the first execution frequency permission, and the first concurrent execution permission.

[0094] Specifically, the first execution trigger permission refers to whether the first user account has the authority to trigger the execution of a specific instruction. The first execution time window permission refers to the time period within which the first user account can execute instructions. The first execution frequency permission refers to the number of times the first user account can execute instructions within a specific time window. The first concurrent execution permission refers to the number of instructions the first user account can execute simultaneously.

[0095] For example, the server obtains the first user list of the current application and the first execution permission of the first user account in the first user list corresponding to the main instruction type from the data storage system; based on at least one of the first execution trigger permission, first execution time window permission, first execution frequency permission, and first concurrent execution permission of the first user account, the server configures the first security configuration file corresponding to the first user account.

[0096] In this embodiment, the first user list of the current application and the first execution permissions of the first user accounts in the first user list corresponding to the main instruction type are obtained. Then, based on the first execution permissions of the first user accounts, the first security configuration file corresponding to the first user account is configured. Different execution trigger permissions, execution time window permissions, execution frequency permissions, and concurrent execution permissions are defined for different user accounts to perform detailed verification of the execution of the current user instructions. Furthermore, the first security configuration file can be dynamically adjusted according to the changes in user account permissions, which can quickly respond to the needs of business changes and has high flexibility. At the same time, configuring concurrent execution permissions can also effectively improve the efficiency of system resource utilization and optimize the use of system resources.

[0097] In one embodiment, a second security verification is performed on the second execution permission of the lower-level sub-instruction based on a second security configuration file to obtain a second security verification result, including:

[0098] Obtain the second security configuration file corresponding to the lower-level sub-instruction; verify the second execution permission of the lower-level sub-instruction according to the second security configuration file, and obtain the second security verification result.

[0099] The second security configuration file is configured to grant second execution permissions for the sub-instruction types of the current application. Specifically, similar to the first security configuration file, the second security configuration file is pre-generated and stored in the server's data storage system. It defines in detail the various permissions for the instructions corresponding to the sub-instruction types during execution, used to determine whether the execution of the instructions conforms to the preset security policy.

[0100] For example, the server retrieves the second security configuration file corresponding to the lower-level sub-instruction from the data storage system; and performs detailed verification of the second execution permission of the lower-level sub-instruction based on the second security configuration file to obtain the second security verification result.

[0101] In this embodiment, the server obtains the second security configuration file corresponding to the lower-level sub-instruction and verifies the second execution permission of the lower-level sub-instruction according to the second security configuration file. This allows the server to obtain the second security verification result corresponding to the second execution permission. This enables the server to perform matching verification on the lower-level sub-instruction before its execution, ensuring that the execution of all lower-level sub-instructions complies with the preset security policy, thereby improving the security of system operation.

[0102] In one embodiment, before obtaining the second security configuration file corresponding to the lower-level sub-instruction, the method further includes:

[0103] Obtain the second user list of the current application and the second execution permissions of the corresponding sub-instruction types for each second user account in the second user list; based on the second execution permissions of each second user account, configure the second security configuration file corresponding to the second user account.

[0104] The second user list refers to the list of registered or authorized users in the current application. This list includes each user's second user account and the second execution permissions corresponding to each user account's sub-instruction type. The second user account serves as a unique identifier for each user and can be a username, user ID, or other information that distinguishes different users. The second user list is the same as or similar to the first user list. Since sub-instructions belong to the main instruction, the second user accounts in the second user list belong to the first user accounts in the first user list; that is, the first user accounts contain all the second user accounts. Furthermore, the second user list can also be based on the first user list, with corresponding second execution permissions added to the second user accounts to reduce system storage resource consumption. The second user list can be pre-stored in a data storage system or obtained from an external device during configuration.

[0105] The second execution permission includes at least one of the following: second execution trigger permission, second execution time window permission, second execution frequency permission, and second concurrent execution permission for the second user account regarding instructions belonging to the sub-instruction type. The second execution trigger permission, second execution time window permission, second execution frequency permission, and second concurrent execution permission are similar to the first execution trigger permission, first execution time window permission, first execution frequency permission, and first concurrent execution permission in the above embodiments, except for the instruction type. For details, please refer to the descriptions in the above embodiments; this embodiment will not repeat them.

[0106] For example, the server obtains the second user list of the current application and the second execution permissions of the corresponding sub-instruction types of the second user accounts in the second user list from the data storage system; based on at least one of the second execution trigger permissions, second execution time window permissions, second execution frequency permissions, and second concurrent execution permissions of the second user accounts, the server configures the second security configuration file corresponding to the second user accounts.

[0107] In this embodiment, the second user list of the current application and the second execution permissions of each second user account in the second user list corresponding to the sub-instruction type are obtained. Then, based on the second execution permissions of each second user account, the second security configuration file corresponding to the second user account is configured. Similarly, different execution trigger permissions, execution time window permissions, execution frequency permissions, and concurrent execution permissions are defined for different user accounts to perform detailed verification of the execution of lower-level sub-instructions. Furthermore, the second security configuration file can be dynamically adjusted according to changes in user account permissions, enabling rapid response to changes in business requirements and providing high flexibility. At the same time, configuring concurrent execution permissions can also effectively improve the efficiency of system resource utilization and optimize system resource utilization.

[0108] In one embodiment, the secure operation method of the above application further includes at least one of the following:

[0109] If the first security verification fails, the execution of the current user's command is rejected and the first exception log is recorded.

[0110] The first exception log refers to the log file used to record the event of verification failure and the current user's instruction being refused execution when the first security verification result is verification failure and the current user's instruction is refused execution. The relevant information includes, but is not limited to, the time of occurrence, the user account, the content of the current user's instruction, and the reason for the verification failure.

[0111] For example, if the first security verification result is that the verification fails, the server refuses to execute the current user's command and records the first exception log.

[0112] If the second security verification result is that the verification fails, the execution of the lower-level sub-instruction is rejected and the second exception log is recorded.

[0113] The second exception log refers to a log file used to record the event of verification failure and the refusal to execute the lower-level sub-instruction when the second security verification result is verification failure and the lower-level sub-instruction is refused to be executed, as well as related information. The related information includes, but is not limited to, the time of occurrence, user account, the content of the current user instruction, and the reason for verification failure.

[0114] For example, if the second security verification result is that the verification fails, the server refuses to execute the lower-level sub-instruction and logs the second exception.

[0115] In this embodiment, by logging the verification of the current user command and its subordinate sub-commands, detailed tracking information and records of the command verification operation can be provided to support compliance review and security incident investigation, and it is also beneficial to conduct a comprehensive post-event analysis of the current application's operation.

[0116] In one embodiment, the secure operation method of the above application further includes at least one of the following:

[0117] When the instruction type is a sub-instruction type and the current user instruction is an executable instruction, the second execution permission of the current user instruction is verified based on the second security configuration file to obtain the third security verification result; when the third security verification result is successful, the current user instruction is executed to obtain the execution result of the current user instruction.

[0118] The third verification result refers to the result obtained after verifying the second execution permission of the current user command according to the second security configuration file. The third security verification result can be used to indicate whether the security verification of the current user command has passed. Passing means that the client has permission to execute the current user command, and failing means that the client does not have permission to execute the current user command.

[0119] For example, when the instruction type of the current user instruction is a sub-instruction type and the current user instruction is an executable instruction, the server performs a security verification on the second execution permission of the current user instruction based on the second security configuration file to determine whether the client has execution permission for the current application, and then obtains a third security verification result; when the third security verification result of the security verification of the second execution permission of the current user instruction is successful, the server executes the current user instruction to obtain the execution result of the current user instruction, thereby enabling the current application to run securely under the action of the current user instruction.

[0120] When the instruction type is a sub-instruction type and the current user instruction is not an executable instruction, or the lower-level sub-instruction is not an executable instruction, an alarm is triggered for the current user instruction and a third exception log is recorded.

[0121] Among them, "not executable instructions" refers to instructions that are not executable by the current user instruction or its subordinate sub-instructions.

[0122] The third exception log refers to the situation where a current user instruction or a lower-level sub-instruction that belongs to the sub-instruction type is not an executable instruction of the current application. In this case, the current user instruction or the lower-level sub-instruction will not be executed, and an alarm will be triggered for the current user instruction. The third exception log is used for information related to the current user instruction or the lower-level sub-instruction not being executed, as well as information related to triggering an alarm for the current user instruction.

[0123] For example, when the instruction type of the current user instruction obtained by the server is a sub-instruction type and the current user instruction is not an executable instruction, the current user instruction will not be executed. The server will issue an alarm for the current user instruction and record the information that the current user instruction was not executed and the alarm information in the third exception log. Alternatively, when the lower-level sub-instruction is not an executable instruction, the lower-level sub-instruction will not be executed. The server will issue an alarm for the current user instruction corresponding to the lower-level sub-instruction and record the information that the lower-level sub-instruction was not executed and the alarm information in the third exception log.

[0124] In this embodiment, by logging the execution process of the current user command and its subordinate sub-commands, detailed tracking information and records can be provided for the execution process of the current application's response commands. This supports compliance reviews and security incident investigations, and facilitates a comprehensive post-event analysis of the current application's operation.

[0125] In one application example, a method for secure application execution is provided. This method is primarily applied in multi-user operating system environments, such as servers, cloud computing infrastructure, and large-scale multitasking systems. In these environments, the system runs multiple applications, each potentially triggered by different user or service accounts. To improve security and ensure the rational allocation of system resources, precise control is needed over the application's execution permissions, time windows, frequency, and command concurrency. The following example uses a polymorphic binary application as an example, where:

[0126] Multicall Binary: A multicall binary is a programming paradigm in which a single binary file can emulate and execute multiple programs, determining which function to execute based on the name of the calling program or the parameters passed to it.

[0127] Permission verification: In software and computer systems, permission verification refers to the process of checking whether a user or program has the right to perform a certain operation or access certain data.

[0128] Time Window Verification: Time window verification refers to the process of checking operation requests within a specific time frame that allows certain operations to be performed.

[0129] Frequency control: Frequency control refers to the process of limiting the number of times a specific operation can be performed within a given time period.

[0130] Concurrency control: Guaranteeing the number of times the same program can run at the same time.

[0131] Resource Management: Resource management refers to the process of allocating, optimizing, and monitoring resources such as CPU, memory, and storage in a computer system.

[0132] BusyBox is a software that integrates multiple UNIX (Uniplexed Information and Computering System) system tools. It is typically used in embedded operating systems and provides a streamlined set of UNIX command-line tools packaged in a single executable file.

[0133] Executable binary files: A special type of binary file that contains machine code that a computer can directly parse and execute. Executable binary files undergo a compilation process that converts source code written in a high-level programming language into instructions that the computer's central processing unit can directly understand and execute.

[0134] Binary applications: These are programs that have been compiled from source code into machine language. Binary applications are packaged into binary format files and can run directly on the computer's operating system. Binary applications directly contain the instruction set that the computer processor can directly interpret and execute.

[0135] Artificial Intelligence (AI): Artificial intelligence (AI) is a branch of computer science that focuses on creating machines and software systems that can perform tasks that typically require human intelligence.

[0136] Service Level Agreement (SLA): A Service Level Agreement (SLA) is a formal agreement between a service provider and a customer that clearly outlines the specific expectations and standards of service.

[0137] Based on the above, the steps in this example are as follows:

[0138] Step 1: Design an application based on a business completion polymorphic binary.

[0139] In this step, for example, a Busybox-like command called `syskits` (example polymorphic binary name) is designed. This integrates over a hundred commonly used Busybox command lines, such as `cp`, `ls`, `rsync`, and `cat`, into a single polymorphic binary named `syskits`. The `ls` command can be executed using `syskits ls [options]`, or a symbolic link to `ls` can be created to directly execute the `ls` command using `ls [options]`. In this embodiment, each tool (such as `ls`, `cp`, etc.) involves an independent module. These modules constitute the main body of the system's command implementation. Each module is independently responsible for the logical processing of a specific command. For the specific design framework, please refer to Figure 3. The main structure includes:

[0140] The command parsing module is responsible for parsing commands submitted by users or the system, determining the command type and parameters, and providing the necessary information for subsequent permission verification and execution.

[0141] The permission verification module is used to verify whether the user or service that initiates the command has sufficient permissions to execute the command, thus ensuring system security.

[0142] The runtime window check module is used to check whether commands are executed within the configured allowed execution time window, such as at night or during off-peak hours, in order to reduce the impact on system performance.

[0143] The command execution frequency check module is used to manage the execution frequency of commands and prevent a single command from running too fast, which could cause system overload. For example, it can limit the execution frequency of certain important commands to ensure system stability.

[0144] The command concurrency check module is used to control the number of identical subcommands that can be executed at the same time, avoiding performance issues caused by resource contention.

[0145] The command routing module is used to quickly find subcommands.

[0146] A general command-line framework that provides parsing and metadata storage interfaces for main commands and subcommands.

[0147] The error handling module is used to handle various abnormal situations.

[0148] The logging module records the execution details of all commands for auditing, monitoring, and troubleshooting.

[0149] Step 2: Deploy the polymorphic binary program to the corresponding environment.

[0150] Step 3: Create a secure execution control configuration file. The secure execution control configuration file is a detailed configuration file that defines the execution permissions, time windows, frequency, and command concurrency limits for each command.

[0151] Configuration template:

[0152] The detailed configuration information is explained below:

[0153] Users: Align with system users; if not set, the default is no restriction.

[0154] cmd: Business commands configured for secure execution of control settings. For example, there is a Busybox-like command called syskits, which integrates more than a hundred commonly used Busybox command lines such as cp, ls, rsync, and cat into a polymorphic binary syskits. You can use syskits ls [options] to execute the ls command, or you can use an ls symbolic link to syskits and directly use ls [options] to execute the ls command.

[0155] time_window: Runtime window.

[0156] frequency: Operating frequency setting.

[0157] max_concurrency: Concurrent operation setting.

[0158] Example scenario: In a data center environment, a server needs to perform multiple data backup tasks, which have strict requirements on execution time and resource usage.

[0159] Configuration example: Generate a configuration file named syskits.conf in / etc / on the Linux system to restrict the subcommand permissions of polymorphic binary syskits.

[0160] Step 4: Dynamic permission check, command secure execution control flow is shown in Figure 4.

[0161] Before each command is executed, the system dynamically checks whether the current user and system time meet the permissions and conditions set in the configuration file, ensuring that command execution follows the preset security policy.

[0162] Step 5: Command execution and security monitoring. The overall process is shown in Figure 5.

[0163] If the check passes, the command is executed; otherwise, execution is refused and the relevant event is logged, ensuring that commands are executed only under authorized conditions, thereby improving system security and resource utilization efficiency.

[0164] Furthermore, this example can also be applied in cloud service provider environments, where the command execution strategy can be dynamically adjusted according to customer needs to adapt to different service level agreements (SLAs).

[0165] For example, the integration of SLA parameters, such as maximum response time and availability requirements, into the configuration file allows command execution strategies to be dynamically adjusted according to the SLAs of different customers.

[0166] For example, AI-based command scheduling optimization uses AI algorithms to analyze historical execution data, optimize command scheduling and resource allocation, improve command execution efficiency, optimize resource utilization, and meet higher service standards.

[0167] Therefore, this example has the following beneficial effects:

[0168] 1. Dynamic permission management

[0169] Dynamic access control offers enhanced security and flexibility. By dynamically specifying which user roles can execute specific commands at specific times through configuration files, it can adapt to ever-changing business and security needs, thereby more effectively preventing unauthorized access.

[0170] 2. Time window control

[0171] By limiting the time window for command execution (such as allowing certain operations to be performed only at night or during off-peak hours), the system's security and performance are significantly improved, the potential exposure of security vulnerabilities during critical periods is reduced, and the use of system resources is optimized.

[0172] 3. Command execution frequency and concurrency limits

[0173] Limiting the number of concurrent commands prevents excessive use of system resources and potential denial-of-service (DoS) attacks. By limiting the number or frequency of concurrent command executions, such as the number of executions per hour or per day, the system can process requests more smoothly and avoid exhausting resources in a short period of time.

[0174] 4. Configuration file parsing and application

[0175] Through efficient configuration file parsing and application, rapid permission updates and command control are achieved, significantly reducing the complexity of system maintenance and the possibility of errors, and enabling rapid response to changes in permissions and policies.

[0176] 5. Auditing and logging

[0177] Comprehensive auditing and logging capabilities provide detailed tracking and recording of system operations, thereby supporting compliance reviews and security incident investigations.

[0178] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0179] Based on the same inventive concept, this application also provides a secure application operation apparatus for implementing the secure operation method of the application described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more embodiments of the secure application operation apparatus provided below can be found in the limitations of the secure application operation method described above, and will not be repeated here.

[0180] In an exemplary embodiment, as shown in FIG6, a secure application execution device is provided, comprising: an instruction parsing module 601, an instruction type determination module 602, a first verification module 603, a lower-level instruction acquisition module 604, a second verification module 605, and an instruction execution module 606. Wherein:

[0181] The instruction parsing module 601 is used to obtain the current user instruction for the current application, parse the current user instruction, and obtain the first metadata of the current user instruction.

[0182] The instruction type determination module 602 is used to determine the instruction type of the current user instruction based on the first metadata.

[0183] The first verification module 603 is used to perform security verification on the first execution permission of the current user command based on the first security configuration file when the command type is the main command type, and obtain the first security verification result.

[0184] The lower-level instruction acquisition module 604 is used to acquire the lower-level sub-instruction of the current user instruction from the first metadata when the first security verification result is successful.

[0185] The second verification module 605 is used to perform security verification on the second execution permission of the lower-level sub-instruction based on the second security configuration file when it is determined that the lower-level sub-instruction is an executable instruction, and obtain the second security verification result.

[0186] The instruction execution module 606 is used to execute the next-level sub-instruction and obtain the execution result of the current user instruction when the second security verification result is successful.

[0187] In an optional embodiment, the first verification module 603 is further configured to obtain a first security configuration file corresponding to the current user instruction; the first security configuration file is obtained by configuring the first execution permission for the main instruction type of the current application; the first execution permission of the current user instruction is verified according to the first security configuration file to obtain a first security verification result.

[0188] In an optional embodiment, the first verification module 603 is further configured to obtain a first user list of the current application and a first execution permission corresponding to the main instruction type of each first user account in the first user list; the first execution permission includes at least one of the first execution trigger permission, first execution time window permission, first execution frequency permission, and first concurrent execution permission of the first user account for instructions belonging to the main instruction type; and configure a first security configuration file corresponding to the first user account based on the first execution permission of each first user account.

[0189] In an optional embodiment, the second verification module 605 is further configured to obtain a second security configuration file corresponding to the lower-level sub-instruction; the second security configuration file is obtained by configuring the second execution permission for the sub-instruction type of the current application; the second execution permission of the lower-level sub-instruction is verified according to the second security configuration file to obtain a second security verification result.

[0190] In an optional embodiment, the second verification module 605 is further configured to obtain the second user list of the current application and the second execution permissions of each second user account in the second user list corresponding to the sub-instruction type; the second execution permissions include at least one of the second execution trigger permissions, second execution time window permissions, second execution frequency permissions, and second concurrent execution permissions of the second user account for instructions belonging to the sub-instruction type; and configure the second security configuration file corresponding to the second user account based on the second execution permissions of each second user account.

[0191] In an optional embodiment, the secure operation device of the above application further includes a third verification module, which is used to perform security verification on the second execution permission of the current user instruction based on the second security configuration file when the instruction type is a sub-instruction type and the current user instruction is an executable instruction, and obtain a third security verification result; when the third security verification result is that the verification is passed, the current user instruction is executed to obtain the execution result of the current user instruction.

[0192] In an optional embodiment, the secure operation device of the above application further includes a first log recording module, which is used to refuse the execution of the current user instruction and record a first exception log when the first security verification result is that the verification fails.

[0193] In an optional embodiment, the secure operation device for the above application further includes a second logging module, which is used to refuse the execution of the lower-level sub-instruction and record a second exception log when the second security verification result is that the verification fails.

[0194] In an optional embodiment, the secure operation device of the above application further includes a third log recording module, which is used to issue an alarm and record a third abnormal log for the current user instruction when the instruction type is a sub-instruction type and the current user instruction is not an executable instruction, or the lower-level sub-instruction is not an executable instruction.

[0195] The modules in the secure operation device of the aforementioned application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of the computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0196] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram is shown in Figure 7. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores a first security configuration file, a second security configuration file, a first user list and first execution permissions for a first user account, a second user list and second execution permissions for a second user account, various log information, etc. The I / O interfaces of the computer device are used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a secure operation method for an application.

[0197] Those skilled in the art will understand that the structure shown in Figure 7 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0198] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the secure operation method of the application described in the above embodiment.

[0199] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the secure operation method of the application described above.

[0200] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements a secure operation method for the application described above.

[0201] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0202] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0203] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0204] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for securely running an application, characterized in that, The method includes: Obtain the current user instruction for the current application, parse the current user instruction, and obtain the first metadata of the current user instruction; The instruction type of the current user instruction is determined based on the first metadata; When the instruction type is the primary instruction type, the first execution permission of the current user instruction is verified based on the first security configuration file to obtain the first security verification result. When the first security verification result is successful, the next-level sub-instruction of the current user instruction is obtained from the first metadata; When it is determined that the lower-level sub-instruction is an executable instruction, a security verification is performed on the second execution permission of the lower-level sub-instruction based on the second security configuration file, and a second security verification result is obtained; and When the second security verification result is successful, the lower-level sub-instruction is executed to obtain the execution result of the current user instruction.

2. The method according to claim 1, characterized in that, The security verification of the first execution permission of the current user instruction based on the first security configuration file, to obtain the first security verification result, includes: Obtain the first security configuration file corresponding to the current user instruction; the first security configuration file is obtained by configuring the first execution permission for the main instruction type of the current application; and The first execution permission of the current user's instruction is verified according to the first security configuration file to obtain the first security verification result.

3. The method according to claim 2, characterized in that, Before obtaining the first security configuration file corresponding to the current user instruction, the method further includes: Obtain the first user list of the current application and the first execution permissions corresponding to the main instruction type for each first user account in the first user list; the first execution permissions include at least one of the following: first execution trigger permission, first execution time window permission, first execution frequency permission, and first concurrent execution permission for the first user account for instructions belonging to the main instruction type; and Based on the first execution permissions of each of the first user accounts, configure the first security configuration file corresponding to the first user account.

4. The method according to claim 1, characterized in that, The security verification of the second execution permission of the lower-level sub-instruction based on the second security configuration file, to obtain the second security verification result, includes: Obtain the second security configuration file corresponding to the lower-level sub-instruction; the second security configuration file is obtained by configuring the second execution permission for the sub-instruction type of the current application; and The second execution permission of the lower-level sub-instruction is verified according to the second security configuration file to obtain the second security verification result.

5. The method according to claim 4, characterized in that, Before obtaining the second security configuration file corresponding to the lower-level sub-instruction, the method further includes: Obtain the second user list of the current application and the second execution permissions corresponding to the sub-instruction types of each second user account in the second user list; the second execution permissions include at least one of the following: second execution trigger permission, second execution time window permission, second execution frequency permission, and second concurrent execution permission for the second user account regarding instructions belonging to the sub-instruction type; and Based on the second execution permissions of each of the second user accounts, configure the second security configuration file corresponding to the second user account.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the first security verification result is that the verification fails, the execution of the current user instruction is rejected and the first exception log is recorded.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the second security verification result is that the verification fails, the execution of the lower-level sub-instruction is rejected and a second exception log is recorded.

8. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the instruction type is a sub-instruction type and the current user instruction belongs to the executable instruction, the second execution permission of the current user instruction is verified based on the second security configuration file to obtain a third security verification result; when the third security verification result is successful, the current user instruction is executed to obtain the execution result of the current user instruction.

9. The method according to any one of claims 1 to 5, characterized in that, The method further includes: When the instruction type is a sub-instruction type and the current user instruction does not belong to the executable instruction, or the lower-level sub-instruction does not belong to the executable instruction, an alarm is triggered for the current user instruction and a third abnormal log is recorded.

10. A secure operating device for an application, characterized in that, The device includes: The instruction parsing module is used to obtain the current user instruction for the current application, parse the current user instruction, and obtain the first metadata of the current user instruction; The instruction type determination module is used to determine the instruction type of the current user instruction based on the first metadata. The first verification module is used to perform security verification on the first execution permission of the current user instruction based on the first security configuration file when the instruction type is the main instruction type, and obtain the first security verification result. The lower-level instruction acquisition module is used to acquire the lower-level sub-instruction of the current user instruction from the first metadata when the first security verification result is verification passed. The second verification module is used to perform security verification on the second execution permission of the lower-level sub-instruction based on the second security configuration file when it is determined that the lower-level sub-instruction is an executable instruction, and obtain a second security verification result; and The instruction execution module is used to execute the lower-level sub-instruction when the second security verification result is successful, and obtain the execution result of the current user instruction.

11. The apparatus according to claim 10, characterized in that, The first verification module is further configured to: Obtain the first security configuration file corresponding to the current user instruction; the first security configuration file is obtained by configuring the first execution permission for the main instruction type of the current application; and The first execution permission of the current user's instruction is verified according to the first security configuration file to obtain the first security verification result.

12. The apparatus according to claim 10, characterized in that, The first verification module is further configured to: Obtain the first user list of the current application and the first execution permissions of each first user account in the first user list corresponding to the main instruction type; the first execution permissions include at least one of the following: first execution trigger permission, first execution time window permission, first execution frequency permission, and first concurrent execution permission for the first user account for instructions belonging to the main instruction type; and Based on the first execution permissions of each of the first user accounts, configure the first security configuration file corresponding to the first user account.

13. A computer device comprising a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method according to any one of claims 1 to 9.

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

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

Images