Command execution method and device, electronic device, storage medium and product

Abstract

The application discloses an execution method and device of a command, electronic equipment, a storage medium and a product. The method comprises the following steps: obtaining an executable command, determining isolation execution environment configuration information corresponding to the executable command, and performing security evaluation on the executable command to obtain an evaluation result; in the case that the evaluation result represents that a preset security policy is met, generating an isolation execution environment according to the isolation execution environment configuration information; executing the executable command in the isolation execution environment, and obtaining output data and an exit code of the executable command; after the executable command is executed, determining a disposal result for a temporary writable layer; encapsulating the output data, the exit code and the disposal result, and sending the encapsulation result to a sending object of the executable command. The application solves the technical problems that a related command execution mode is prone to cause persistent pollution of a host file system, lacks a security isolation mechanism and a default back-off mechanism.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and more specifically, to a command execution method, apparatus, electronic device, storage medium, and product. Background Technology

[0002] In scenarios such as Security Operations Centers (SOCs), agents deployed on managed hosts often need to execute custom commands to complete operational tasks. Related technologies either execute commands directly in the host environment's shell or rely on complete containers with high startup costs for isolation. The former lacks effective isolation, making the host file system susceptible to malicious modification or persistent pollution; the latter, while possessing isolation capabilities, struggles to balance resource overhead and audit closure in high-frequency, short-duration tasks, and often lacks an automatic state rollback mechanism after task completion, resulting in residual changes to the host environment and failing to meet security compliance requirements for default non-pollution and traceability.

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

[0004] This application provides a command execution method, apparatus, electronic device, storage medium, and product to at least solve the technical problems that related command execution methods easily lead to persistent pollution of the host file system, lack of security isolation, and default rollback mechanism.

[0005] According to one aspect of this application, a method for executing a command is provided, comprising: obtaining an executable command; determining the configuration information of an isolated execution environment corresponding to the executable command; performing a security assessment on the executable command to obtain an assessment result; if the assessment result indicates that a preset security policy is met, generating an isolated execution environment according to the isolated execution environment configuration information, wherein the isolated execution environment includes at least: a read-only root layer and a temporary writable layer; the read-only root layer is constructed based on the host file system and is used to provide a read-only file system for the execution of the executable command; the temporary writable layer is used to carry the write data generated by the executable command during execution; executing the executable command within the isolated execution environment and obtaining the output data and exit code of the executable command; after executing the executable command, determining the disposal result for the temporary writable layer, wherein the disposal result includes: deleting the temporary writable layer if the preset authorization conditions are not met; merging the changed content in the temporary writable layer into the host file system if the preset authorization conditions are met; encapsulating the output data, exit code, and disposal result, and sending the encapsulation result to the sending object of the executable command.

[0006] Optionally, the isolated execution environment also includes: namespace isolation configuration, system call filtering policy, and network access control policy; generating the isolated execution environment according to the isolated execution environment configuration information includes: mounting the host file system to the child process in a read-only binding manner to obtain a read-only root layer, wherein the child process is a process initiated by the agent to host the isolated execution environment; creating a temporary writable layer in the child process and superimposing the temporary writable layer on the read-only root layer, so that the content in the read-only root layer can be accessed in read-only mode, and the write data generated during execution is written to the temporary writable layer; isolating the process namespace of the child process according to the namespace selection item in the isolated execution environment configuration information to obtain the namespace isolation configuration; loading a system call filtering policy for the child process according to the system call filtering item in the isolated execution environment configuration information, wherein the system call filtering policy is used to allow the child process to initiate system calls within a preset range and to block system calls outside the preset range according to the system call filtering item; isolating the network namespace of the child process according to the network control item in the isolated execution environment configuration information, or configuring firewall rules for the child process to obtain the network access control policy.

[0007] Optionally, the isolated execution environment configuration information also includes: a mount allow list and a controlled access identifier, wherein the mount allow list is a pre-configured set of host directories that are allowed to be bound and mounted to the isolated execution environment; the controlled access identifier is used to indicate whether the execution of the executable command requires approval; generating the isolated execution environment according to the isolated execution environment configuration information includes: binding and mounting the host directories in the host file system that match the mount allow list to the isolated execution environment according to the mount allow list; configuring the system call filtering policy's allowed system call range according to the system call filtering item in the isolated execution environment configuration information; configuring the network access control policy's allowed network access range according to the network control item in the isolated execution environment configuration information; executing the executable command within the isolated execution environment includes: obtaining the approval result for the executable command if the controlled access identifier indicates that approval is required; and executing the executable command if the approval result indicates that approval is required.

[0008] Optionally, an isolated execution environment is generated based on the isolated execution environment configuration information, including: determining the pre-configured container image corresponding to the isolated execution environment configuration information, wherein the container image includes: the root file system required for the execution of executable commands; loading the container image in read-only mode to obtain a read-only root layer; creating a container storage layer or temporary directory as a temporary writable layer, and overlaying the temporary writable layer on top of the read-only root layer, so that the write data generated during the execution of the executable command is written to the temporary writable layer and the container image remains read-only; after executing the executable command, determining the disposal result for the temporary writable layer, including: completing the disposal of the temporary writable layer by deleting the container storage layer or temporary directory corresponding to the temporary writable layer, and obtaining the disposal result.

[0009] Optionally, a security assessment is performed on the executable command to obtain an assessment result, including: if a preset assessment model is available, performing a security assessment on the executable command using the preset assessment model to obtain an assessment result; if the preset assessment model is unavailable, performing a security assessment on the executable command using a preset rule table to obtain an assessment result; wherein the assessment result includes the risk level of the executable command; both the preset assessment model and the preset rule table use the same configuration switching logic to determine the isolation execution environment configuration information corresponding to the executable command; after performing a security assessment on the executable command and obtaining the assessment result, the method further includes: if the risk level is greater than or equal to a preset risk threshold, refusing to execute the executable command, or switching the isolation execution environment configuration information corresponding to the executable command to a preset enhanced isolation configuration, wherein the system call range allowed by the enhanced isolation configuration is smaller than the system call range allowed before the switch, and the network control item in the enhanced isolation configuration indicates that the execution process of the executable command is prohibited from accessing the network.

[0010] Optionally, generating an isolated execution environment based on the isolated execution environment configuration information includes: determining the intent category and risk identifier of an executable command, wherein the intent category is used to characterize the operation type of the executable command, and the risk identifier is used to characterize the preset risk operation contained in the executable command; obtaining a preset configuration template, wherein the configuration template is used to determine the basic isolation constraints of the isolated execution environment, the basic isolation constraints including at least one of the following: a namespace set, a system call filter set, and a network access policy that is denied by default; determining a target incremental configuration fragment that matches the intent category and risk identifier from multiple preset incremental configuration fragments, wherein the incremental configuration fragment is used to adjust the configuration items corresponding to the intent category and risk identifier based on the basic isolation constraints; merging the target incremental configuration fragment into the configuration template to obtain the isolated execution environment configuration information; wherein, when the configuration template and the target incremental configuration fragment conflict for the same configuration item, they are merged according to a preset security priority rule, the security priority rule including: when the conflict involves the relaxation and tightening of access permissions, the tightened configuration item is used to cover the relaxed configuration item to obtain the merged configuration item; generating the isolated execution environment based on the isolated execution environment configuration information.

[0011] Optionally, before obtaining the executable command, the method further includes: parsing the preset configuration template during idle periods to obtain the compiled policy handle corresponding to the configuration template; creating a general writable storage layer directory and a temporary file system mount point; and storing the compiled policy handle, the writable storage layer directory, and the temporary file system mount point into the preheating resource pool.

[0012] Optionally, generating an isolated execution environment based on the isolated execution environment configuration information includes: determining whether a compiled policy handle and an idle writable storage layer directory matching the isolated execution environment configuration information exist in the preheating resource pool; if the determination result is that they exist, performing the following steps: obtaining matching resources from the preheating resource pool, wherein the matching resources include: a compiled policy handle, a writable storage layer directory, and a temporary file system mount point; binding the matching resources with the task identifier of the executable command to obtain the isolated execution environment; if the determination result is that they do not exist, performing the following steps: parsing the configuration template to obtain the target compiled policy handle corresponding to the executable command; creating the target writable storage layer directory and the target temporary file system mount point corresponding to the executable command; binding the target compiled policy handle, the target writable storage layer directory, and the target temporary file system mount point with the task identifier of the executable command to obtain the isolated execution environment; after executing the executable command, the method further includes: adding the resources corresponding to the isolated execution environment configuration information to the preheating resource pool.

[0013] According to another aspect of this application, a command execution apparatus is also provided, comprising: a first acquisition module, configured to acquire an executable command, determine isolated execution environment configuration information corresponding to the executable command, and perform a security assessment on the executable command to obtain an assessment result; and a generation module, configured to generate an isolated execution environment based on the isolated execution environment configuration information, provided that the assessment result indicates that a preset security policy is met, wherein the isolated execution environment includes at least: a read-only root layer and a temporary writable layer; the read-only root layer is constructed based on the host file system and is used to provide a read-only file system for the execution of the executable command; the temporary writable layer is used to carry... The executable command generates write data during execution; a second acquisition module is used to execute the executable command in an isolated execution environment and acquire the output data and exit code of the executable command; a determination module is used to determine the handling result for the temporary writable layer after executing the executable command, wherein the handling result includes: deleting the temporary writable layer if the preset authorization conditions are not met; merging the changed content in the temporary writable layer into the host file system if the preset authorization conditions are met; and an encapsulation module is used to encapsulate the output data, exit code, and handling result, and send the encapsulation result to the sending object of the executable command.

[0014] Optionally, before the executable command is executed, the method further includes: calculating the check value of executable content within a preset check range in the read-only root layer to obtain a baseline check value, wherein the preset check range is part or all of the paths in the read-only root layer declared by the isolated execution environment configuration information; after the executable command is executed, the method further includes: recalculating the check value of the executable content to obtain a verification check value; comparing the verification check value with the baseline check value to obtain an integrity check result; if the integrity check result indicates that the verification check value and the baseline check value are inconsistent, deleting the temporary writable layer and prohibiting the merging of changes in the temporary writable layer into the host file system. According to another aspect of this application, an electronic device is also provided, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above command execution method during runtime.

[0015] According to another aspect of this application, a non-volatile storage medium is also provided, the storage medium including a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above-mentioned commands.

[0016] According to another aspect of this application, a computer program is also provided, wherein when the computer program is executed by a processor, it implements the above-described method for executing commands. In this application, the following steps are taken: obtaining an executable command, determining the configuration information of the isolated execution environment corresponding to the executable command, and performing a security assessment on the executable command to obtain an assessment result; if the assessment result indicates that a preset security policy is met, an isolated execution environment is generated according to the isolated execution environment configuration information, wherein the isolated execution environment includes at least: a read-only root layer and a temporary writable layer; the read-only root layer is constructed based on the host file system and is used to provide a read-only file system for the execution of the executable command; the temporary writable layer is used to carry the write data generated by the executable command during execution; the executable command is executed within the isolated execution environment, and the output data and exit code of the executable command are obtained; after executing the executable command, the processing result for the temporary writable layer is determined, wherein... The processing results include: deleting the temporary writable layer if the preset authorization conditions are not met; merging the changes in the temporary writable layer into the host file system if the preset authorization conditions are met; and encapsulating the output data, exit code, and processing results, and sending the encapsulation results to the sending object of the executable command. This achieves the purpose of executing commands in an isolated and restricted file system level, and automatically cleaning up or retaining the execution changes according to the authorization policy. This achieves the technical effects of ensuring that the host file system is free from persistent pollution by default, providing a strong security isolation barrier, and ensuring that the entire execution process is auditable and traceable. In turn, it solves the technical problems that related command execution methods are prone to causing persistent pollution of the host file system and lack security isolation and default rollback mechanisms. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of a command execution method according to an embodiment of this application;

[0019] Figure 2 This is a flowchart of another command execution method according to an embodiment of this application;

[0020] Figure 3 This is a timing diagram of a read-only root, a temporary writable layer, and discard according to an embodiment of this application;

[0021] Figure 4 This is a schematic diagram illustrating a Profile mapping with dual backends and an expanded task result field according to an embodiment of this application;

[0022] Figure 5This is a structural diagram of a command execution device according to an embodiment of this application;

[0023] Figure 6 This is a hardware structure block diagram of a computer terminal for a command execution method according to an embodiment of this application. Detailed Implementation

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

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

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

[0027] Figure 1 This is a flowchart of a command execution method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0028] Step S101: Obtain the executable command, determine the configuration information of the isolated execution environment corresponding to the executable command, and perform a security assessment on the executable command to obtain the assessment result.

[0029] In step S101, the client agent deployed on the target host for securely isolating and executing commands and reporting results receives custom commands issued by the platform or submitted by the user. These custom commands may include command strings (such as Shell commands), task IDs, agent IDs, and optional sandbox profile IDs.

[0030] Furthermore, the command to be executed is parsed, and its intent and potential risks are identified. Based on the pre-configured or platform-delivered Sandbox Profile Library, the isolation execution environment configuration information (i.e., the sandbox profile) corresponding to the command is determined. This isolation execution environment configuration information defines the namespace isolation level during execution, the mount path of the read-only root file system, network access policies, system call filtering rules (such as Seccomp rules), and resource quota limits, etc.

[0031] Next, a security assessment is performed on the executable command. Assessment methods can include static analysis based on a rule engine or intent recognition based on a lightweight model. For example, it can detect whether the command contains high-risk operations (such as `rm -rf / `, modifying critical system configuration files, or large-scale network fetching). Based on the assessment results, an assessment result is generated, which characterizes whether the executable command meets a preset security policy. For example, the preset security policy can include: allowing execution, restricting execution (such as allowing only read-only access or outbound traffic from specific networks), or denying execution.

[0032] Step S102: If the evaluation result indicates that the preset security policy is met, an isolated execution environment is generated according to the isolated execution environment configuration information. The isolated execution environment includes at least: a read-only root layer and a temporary writable layer. The read-only root layer is built on the host file system and is used to provide a read-only file system for the execution of executable commands. The temporary writable layer is used to carry the write data generated by the executable commands during the execution process.

[0033] In step S102, the construction of the isolated execution environment includes the following key components:

[0034] Lower Layer (Read-Only): Based on configuration information, the agent mounts a read-only directory (or a pre-configured minimal rootfs image) on the host file system as a lower layer. This lower layer includes the basic toolchain required for command execution (such as bash, grep, curl, etc.) and system library files. Because it is mounted in read-only mode, any attempt to modify files in this layer will be intercepted or redirected by the operating system kernel.

[0035] Upper Layer: The agent creates a temporary directory (Upper / Workdir) as a writable layer in the host machine's temporary storage area (such as / tmp or a dedicated isolated directory), and mounts it together with the read-only root layer via the OverlayFS mechanism. In the view after the joint mount, this upper layer is at the top. When file write, creation, or deletion operations occur during command execution, these changes are only recorded in the upper layer and do not directly modify the read-only root layer or the actual file system of the host machine.

[0036] In addition, the Agent can configure other isolation attributes based on the configuration information, such as creating independent PID namespaces (isolate process lists), network namespaces (isolate network interfaces), and loading Seccomp filters (restrict system calls).

[0037] Step S103: Execute the executable command in the isolated execution environment and obtain the output data and exit code of the executable command.

[0038] In step S103, the Agent starts a child process to execute executable commands within the generated isolated execution environment context. Due to the limitations of the isolated environment, the execution scope of the commands is strictly limited to the virtual file system view and network environment.

[0039] The agent monitors the execution process of commands, capturing the command's standard output (stdout), standard error output (stderr), and exit code after execution. The exit code indicates the success or failure of command execution and is a crucial indicator of the task's outcome. Simultaneously, the agent can record resource usage (such as CPU and memory consumption) and security event logs (such as system call attempts intercepted by Seccomp).

[0040] Step S104: After executing the executable command, determine the processing result for the temporary writable layer. The processing result includes: if the preset authorization conditions are not met, delete the temporary writable layer; if the preset authorization conditions are met, merge the changed content in the temporary writable layer into the host file system.

[0041] In step S104, after the command execution is completed, the processing method for the temporary writable layer is determined according to preset authorization conditions. The preset authorization conditions can be determined based on task type, user permissions, security assessment results, or explicit user approval instructions.

[0042] In routine operation and maintenance scenarios (such as read-only queries and diagnostic troubleshooting), the authorization conditions for persistent changes are not met by default. In this case, the Agent performs a discard operation, that is, directly deletes or unloads the temporary writable layer. Since the read-only root layer is not modified, the host file system remains consistent before and after the command execution, achieving a default rollback effect and ensuring the security and cleanliness of the host system.

[0043] The merge operation is performed only when specific authorization conditions are met (e.g., the user explicitly requests file change permissions, the change path is on the authorized list, or additional compliance checks are passed). The merge operation persistently applies the changes (such as newly added or modified files) from the temporary writable layer to the host file system. During this process, the agent can further audit the changes and generate a patch list to ensure the security of the merge.

[0044] Step S105: Encapsulate the output data, exit code, and processing result, and send the encapsulation result to the sending object of the executable command.

[0045] In step S105, the Agent encapsulates the execution result in a structured manner. The encapsulated information includes at least: Execution result data: standard output, standard error output, and exit code of the command; Disposal result metadata: identifying whether the temporary writable layer was deleted or merged, and the corresponding disposal reason or policy version; Audit trace fields: including but not limited to task ID, agent ID, sandbox policy ID, policy version number, and disposal flag.

[0046] The Agent sends the encapsulated results to the command sender (such as the SOC platform) through existing task result channels (such as message queues, HTTP callbacks, or Agent heartbeat reporting mechanisms). The sender can update the task status, record audit logs, and confirm the actual changes to the host file system when file change merging is required, based on the processing results and audit fields.

[0047] Through the above steps S102 to S105, the goal of executing commands in an isolated and restricted file system level and automatically cleaning up or retaining execution changes according to the authorization policy is achieved. This achieves the technical effects of ensuring that the host file system is free from persistent pollution by default, providing a strong security isolation barrier, and ensuring that the entire execution process is auditable and traceable.

[0048] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0049] According to some optional embodiments of this application, the isolated execution environment further includes: namespace isolation configuration, system call filtering policy, and network access control policy.

[0050] The isolated execution environment is generated based on the configuration information, which can be achieved through the following steps: The host file system is mounted to the child process in read-only mode, resulting in a read-only root layer. The child process is initiated by the agent and is used to host the isolated execution environment. A temporary writable layer is created within the child process and superimposed on the read-only root layer, allowing read-only access to the content in the read-only root layer and writing data generated during execution to the temporary writable layer. The process namespace of the child process is isolated according to the namespace selection option in the isolated execution environment configuration information, resulting in a namespace isolation configuration. A system call filtering policy is loaded for the child process according to the system call filtering option in the isolated execution environment configuration information. This policy allows the child process to initiate system calls within a preset range and blocks system calls outside the preset range. Finally, the network namespace of the child process is isolated according to the network control option in the isolated execution environment configuration information, or firewall rules are configured for the child process, resulting in a network access control policy.

[0051] In step S102, the virtualization mechanism and resource isolation technology provided by the operating system are used to construct an execution space with strong isolation characteristics for the child process. Specifically, the above process includes the configuration of file system isolation, process namespace isolation, system call filtering, and network access control.

[0052] 1. File system isolation: Construct a read-only root layer and a temporary writable layer.

[0053] The host machine's read-only filesystem (such as a pre-installed minimal rootfs image or a verified read-only system directory, such as / usr, / lib, etc.) is mounted to the child process's filesystem namespace using read-only binding. Specifically, a specified read-only directory on the host machine is bound and mapped to a specific mount point within the child process (e.g., / or / opt / base), forming a read-only root layer. Because of this read-only mounting mode, any attempt by the child process to modify files at this layer will be intercepted or redirected by the kernel, thus ensuring the security and integrity of the underlying operating environment and preventing accidental command writes or malicious tampering with core system files.

[0054] Create an empty temporary directory as a temporary writable layer (upper layer or workdir) in the host machine's temporary storage area (such as a specific subdirectory under / tmp or a dedicated isolated volume). Then, use the mounting mechanism of a union file system (such as OverlayFS in Linux) to overlay this temporary writable layer on top of the read-only root layer to form a new union mount point.

[0055] In a file system with a unified mount, child processes read files directly from the read-only root layer. When a child process attempts to create a new file, modify an existing file, or delete a file, the operating system kernel redirects the operation to a temporary writable layer. In other words, data written during execution is actually stored in the host machine's temporary writable layer, while the read-only root layer remains unchanged. This mechanism not only achieves write isolation but also improves storage efficiency, consuming additional space only when changes occur. When the task ends, if the process chooses to discard the data, simply deleting the temporary writable layer restores the host state.

[0056] 2. Process namespace isolation.

[0057] The system calls operating system kernel interfaces (such as the `unshare` or `clone` system calls) to create a new process namespace and place the child process and all its child processes within this new namespace. Within this namespace, child processes can only view process IDs starting from 1, and cannot view or send signals (such as the `kill` command) to processes in other namespaces on the host machine, or interact with them. This effectively prevents malicious processes within the isolated execution environment from stealing process information from the host machine or launching process injection attacks.

[0058] Depending on the options selected in the configuration information, user namespaces can be selectively created to map user IDs for permission degradation; or mount namespaces can be created to isolate file system views. These operations can be assisted by lightweight tools (such as bubblewrap) to ensure isolation without requiring privileged daemons.

[0059] 3. System call filtering (Seccomp).

[0060] Parse the configuration information to determine the list of system calls that the child process is allowed to initiate. For example, for read-only diagnostic commands, only basic system calls such as read, open (read-only mode), exit, and brk are allowed; for commands that require network access, network-related system calls such as socket, connect, and sendto are additionally allowed.

[0061] Seccomp mode is enabled via the prctl system call, and the filtering rules are compiled into a BerkeleyPacketFilter (BPF) program and attached to the child process. When a system call initiated by the child process is not in the system call list, the process is terminated directly or an error code is returned, thereby preventing the child process from performing high-risk operations such as mprotect (modifying memory permissions), ptrace (tracing other processes), and mount (mounting a file system).

[0062] 4. Network access control.

[0063] Creates an independent network namespace for the child process. Within this namespace, the child process has its own network stack, including a network interface card (NIC), routing table, and firewall rules. By default, no network connections are available within this namespace, thus cutting off direct communication between the child process and the external network or the host network.

[0064] If the configuration allows specific network access, firewall rules (such as iptables, nftables, or eBPF) can be configured within the child process's network namespace. For example, only allowing child processes to initiate TCP / UDP outbound connections to specific internal IP addresses, or blocking all inbound connections. Furthermore, cgroups can be used to limit the network bandwidth of child processes to prevent resource exhaustion attacks.

[0065] The above isolation configuration allows for the construction of a closed, restricted, and auditable isolated execution environment. Within this environment, child processes can only access predefined read-only resources, their write operations are confined to a temporary writable layer, their system calls are strictly filtered, and their network communication is precisely controlled. After command execution, a preset policy can be used to either discard the temporary writable layer (ensuring host-level integrity) or merge changed content (achieving controlled persistence), thereby minimizing security risks while ensuring operational efficiency.

[0066] According to some alternative embodiments of this application, the isolated execution environment configuration information further includes: a mount permission list and a controlled access identifier, wherein the mount permission list is a pre-configured set of host directories that are allowed to be bound and mounted to the isolated execution environment; and the controlled access identifier is used to indicate whether the execution of an executable command requires approval.

[0067] The isolated execution environment is generated based on the configuration information. This can be achieved through the following steps: Based on the mount allow list, bind and mount the host directories in the host file system that match the mount allow list to the isolated execution environment; based on the system call filtering items in the isolated execution environment configuration information, configure the scope of system calls allowed by the system call filtering policy; based on the network control items in the isolated execution environment configuration information, configure the scope of network access allowed by the network access control policy.

[0068] Furthermore, executing executable commands within an isolated execution environment can be achieved through the following steps: if the controlled access identifier indicates that approval is required, obtain the approval result for the executable command; if the approval result indicates that the command has passed, execute the executable command.

[0069] Understandably, in order to further refine the resource configuration and execution process control of the isolated execution environment, the isolated execution environment configuration information (sandbox profile) also includes: mounting allow lists and controlled access identifiers.

[0070] The mount permission list is a pre-configured set of host directories that are allowed to be bound and mounted to the isolated execution environment (BindMount authorization list or mount policy). Since the isolated execution environment uses a read-only root layer by default, if executable commands need to read specific business data (such as log files or configuration files) from the host host or write to specific directories, they must expose the host directories to the sandbox through binding and mounting. The mount permission list is used to limit the scope of this exposure, allowing only host directories on the authorization list to be mounted, preventing commands within the sandbox from illegally accessing sensitive data directories on the host host.

[0071] Controlled access identifiers are used to characterize whether the execution of an executable command requires secondary approval from either a human or a system (approval flag or lenient profile feature). For example, for high-risk commands or specific types of tasks, the controlled access identifier indicates that approval is required; for low-risk commands, the controlled access identifier indicates that approval is not required.

[0072] The creation of an isolated execution environment can be achieved through the following steps.

[0073] Parse the mount permission list in the isolated execution environment configuration information to obtain the set of allowed host directory paths. For each host directory in the mount permission list, create a corresponding mount point within the isolated execution environment, and bind and mount the host directory in the host file system that matches the mount permission list to the isolated execution environment.

[0074] Specifically, the operating system's mount interface (such as mount--bind) is invoked to mount the specified directory on the host machine to the child process's file system namespace in read-only mode (or read-write mode as configured by the policy).

[0075] If a command attempts to access a host directory that is not listed in the mount allowed list, the command will be unable to access the data because the directory is not mounted and the path is not included in the read-only root level, thus achieving data access isolation.

[0076] Furthermore, fine-grained configuration is performed based on other parameters in the isolated execution environment configuration information:

[0077] Based on the system call filtering items (such as the Seccomp policy) in the isolated execution environment configuration information, configure the scope of system calls allowed by the system call filtering policy. Specifically, parse the authorized list, load the corresponding filtering rules (such as the Seccomp-BPF program), and only allow child processes to initiate system calls included in the list, while blocking system calls outside the list, thereby restricting command access to kernel functions.

[0078] Based on the network control items (including network policies or firewall rules) in the isolated execution environment configuration information, configure the network access control policy to define the permitted network access scope. Specifically, configure firewall rules (such as using iptables or nftables) within the child process's network namespace to restrict the child process to access only the IP addresses, ports, and protocols specified in the authorized list, thereby preventing data leakage or unauthorized network communication.

[0079] Furthermore, the executable command can be executed within an isolated execution environment, which can be achieved through the following steps.

[0080] Read the controlled access identifier. If the controlled access identifier indicates that no approval is required, execute the subsequent command execution operation directly. If the controlled access identifier indicates that approval is required, pause execution and send an approval request to the management platform (or the task sending object). The approval request includes the content of the executable command, the command intent, the risk assessment results, and the sandbox policy information to be used. Wait for and obtain the approval result for the executable command.

[0081] If the approval result indicates approval, the executable command continues to be executed within the isolated execution environment. If the approval result indicates rejection or no response is received within a timeout period, command execution is terminated, and an error message or notification of rejection is returned to the sending object, while also logging the audit log.

[0082] Through the above process, this application embodiment not only achieves basic isolation at the file system, process, system call and network layers, but also achieves fine-grained control of data access by mounting an allow list, and achieves compliance approval of high-risk operations by using controlled access identifiers, further improving the security and controllability of command execution in secure operation scenarios.

[0083] In some optional embodiments of this application, generating an isolated execution environment based on the isolated execution environment configuration information can be achieved through the following steps: determining a pre-configured container image corresponding to the isolated execution environment configuration information, wherein the container image includes: a root file system required for the execution of executable commands; loading the container image in read-only mode to obtain a read-only root layer; creating a container storage layer or temporary directory as a temporary writable layer, and superimposing the temporary writable layer on the read-only root layer, so that the write data generated during the execution of executable commands is written to the temporary writable layer and the container image remains read-only.

[0084] In addition, after executing the executable command, the disposal result for the temporary writable layer can be determined by the following steps: by deleting the container storage layer or temporary directory corresponding to the temporary writable layer, the disposal of the temporary writable layer is completed, and the disposal result is obtained.

[0085] It should be noted that when the isolated execution environment configuration information indicates the use of a container runtime (such as the OCI / runc standard) as the execution backend, the specific process of generating the isolated execution environment and handling the writable layer is as follows:

[0086] Based on the isolated execution environment configuration information, determine the corresponding pre-configured container image (base image or rootfs image). This container image encapsulates the root filesystem required for executable commands to run, including the operating system core libraries, necessary command-line tools, and the basic runtime environment. Load this container image into the isolated execution environment in read-only mode to obtain a read-only root layer.

[0087] Create a container storage layer (container layer or WritableLayer) or a temporary directory (upper layer or workdir) as a temporary writable layer.

[0088] A temporary writable layer is overlaid on top of a read-only root layer to form a union file system view (e.g., using OverlayFS or a container storage driver). In this overlay structure, reads take precedence. When an executable command reads a file, if the file exists in the read-only root layer, its content is returned directly; if the file does not exist in the read-only root layer but exists in the temporary writable layer, its content is returned. If an executable command generates write data during execution (such as creating a new file or modifying an existing file), all write operations are redirected and stored in the temporary writable layer. The container image (i.e., the read-only root layer) remains read-only and is not modified. This mechanism achieves the effect of copy-on-write, ensuring that the execution results of commands are only retained in the temporary layer and do not affect the host machine or the base image.

[0089] After executing the executable command, the disposal result (Discard / Commit decision) for the temporary writable layer is determined based on the isolated execution environment configuration information or preset policies. The disposal of the temporary writable layer is completed by deleting the container storage layer corresponding to the temporary writable layer (i.e., destroying the container layer) or the temporary directory (i.e., deleting the working directory), resulting in a disposal result (e.g., discard=true). Through the above deletion operation, all write data generated during command execution is completely cleared, and the isolated execution environment is restored to its initial read-only state, ensuring that there are no persistent files or changes on the host machine resulting from this command execution. In other words, a default discardable write layer mechanism is implemented, effectively preventing the host machine from being contaminated and achieving a safe rollback of execution-and-destruction.

[0090] Through the above process, this embodiment utilizes container image technology to achieve efficient construction of an isolated execution environment, and ensures the purity and security of the host environment after command execution by automatically destroying the temporary writable layer, while reducing the resource overhead caused by image startup.

[0091] As some optional embodiments of this application, the security assessment of the executable command and the resulting assessment can be achieved through the following steps: when a preset assessment model is available, the executable command is assessed using the preset assessment model to obtain an assessment result; when the preset assessment model is unavailable, the executable command is assessed using a preset rule table to obtain an assessment result; wherein, the assessment result includes the risk level of the executable command; both the preset assessment model and the preset rule table use the same configuration switching logic to determine the isolation execution environment configuration information corresponding to the executable command; after the security assessment of the executable command and the resulting assessment, the method further includes: if the risk level is greater than or equal to a preset risk threshold, the executable command is refused to be executed, or the isolation execution environment configuration information corresponding to the executable command is switched to a preset enhanced isolation configuration, wherein the system call range allowed by the enhanced isolation configuration is smaller than the system call range allowed before the switch, and the network control item in the enhanced isolation configuration indicates that the execution process of the executable command is prohibited from accessing the network.

[0092] It should be noted that, in order to ensure both security and flexibility in the assessment, the process of conducting a security assessment of executable commands and obtaining the assessment results can be implemented in the following ways.

[0093] Determine if a pre-defined evaluation model (such as an AI pre-detection model or a lightweight model) is available:

[0094] When a pre-defined evaluation model is available, the executable command is evaluated for security using the pre-defined evaluation model to obtain the evaluation results. The pre-defined evaluation model is used to make intelligent judgments based on the semantics, intent, and risk signals of the command (such as detecting high-risk operation characteristics such as curl, wget, and rm-rf).

[0095] If the preset evaluation model is unavailable (e.g., model loading fails, timeout occurs, or an error occurs), the system automatically switches to the preset rule table. The preset rule table is used to perform a security assessment on the executable commands, and the assessment results are obtained. The rule table performs risk assessment based on predefined deterministic logic such as string matching and keyword interception.

[0096] Regardless of the method used, the assessment results can include the risk level of the executable command (risk_flags or intent_class corresponding to risk ratings, such as high, medium, and low).

[0097] Alternatively, both using a pre-defined evaluation model and using a pre-defined rule table determine the isolated execution environment configuration information corresponding to the executable command through the same configuration switching logic (Profile synthesis rule or merge_log). In other words, regardless of whether an AI model or a rule table is used at the underlying level, the risk level output is ultimately mapped to a unified policy selection algorithm, ensuring the consistency and auditability of policy issuance.

[0098] After obtaining the evaluation results, further processing of the executable commands is possible, including the following:

[0099] The risk level in the assessment results is compared with the preset risk threshold. If the risk level is greater than or equal to the preset risk threshold (i.e., determined to be high risk or extremely high risk), one or a combination of the following two measures will be taken.

[0100] Execution Refusal: Directly terminates the execution flow of the executable command and returns a notification of refusal to the sending object. This is suitable for commands with extremely high risk and no reasonable business scenario (such as directly deleting critical system files).

[0101] Switch to enhanced isolation configuration: If the business policy allows execution under strict restrictions, switch the isolation execution environment configuration information corresponding to the executable command to the preset enhanced isolation configuration (strict_profile or downgrade to Strict mode).

[0102] The enhanced isolation configuration imposes stricter restrictions compared to the previous isolation execution environment configuration. Specifically, the scope of system calls allowed by the enhanced isolation configuration (the Seccomp policy allowed list) is smaller than that allowed before the switch. For example, it tightens the restrictions from allowing regular system calls to only allowing read-only system calls, blocking system calls like execve and mprotect that could be used for code injection or privilege escalation. Network control entries in the enhanced isolation configuration prohibit executable commands from accessing the network. Specifically, when building the isolation execution environment, this is achieved by disconnecting the default route of the network namespace, configuring firewall rules to deny all outbound / inbound traffic, or removing network interfaces, ensuring that commands execute in a completely offline environment to prevent data leaks or botnet communication.

[0103] The above process employs an AI model-first, rule-table-last-resort assessment method. While ensuring high availability of the assessment, it uses unified logic to map risk levels to standardized isolation strategies, achieving tight coupling between risk assessment and execution control. For high-risk commands, it automatically executes rejection or switches to enhanced isolation configurations that tighten system calls and prohibit network access, effectively blocking malicious exploitation paths and significantly improving the defense capabilities and compliance of command execution in security operation scenarios.

[0104] In some optional embodiments of this application, generating an isolated execution environment based on the isolated execution environment configuration information can be achieved through the following steps: determining the intent category and risk identifier of an executable command, wherein the intent category is used to characterize the operation type of the executable command, and the risk identifier is used to characterize the preset risk operation contained in the executable command; obtaining a preset configuration template, wherein the configuration template is used to determine the basic isolation constraints of the isolated execution environment, the basic isolation constraints including at least one of the following: a namespace set, a system call filter set, and a network access policy that is denied by default; determining a target incremental configuration fragment that matches the intent category and risk identifier from a plurality of preset incremental configuration fragments, wherein the incremental configuration fragment is used to adjust the configuration items corresponding to the intent category and risk identifier based on the basic isolation constraints; merging the target incremental configuration fragment into the configuration template to obtain the isolated execution environment configuration information; wherein, when the configuration template and the target incremental configuration fragment conflict for the same configuration item, they are merged according to a preset security priority rule, the security priority rule including: when the conflict involves the relaxation and tightening of access permissions, the tightened configuration item is used to cover the relaxed configuration item to obtain the merged configuration item; generating the isolated execution environment based on the isolated execution environment configuration information.

[0105] It is worth explaining that, in order to overcome the rigidity of fixed configuration file strategies and the inability to balance security and usability issues related to different command intentions, the process of generating isolated execution environment configuration information adopts a dynamic synthesis method, which specifically includes the following steps:

[0106] Semantic analysis is performed on executable commands to determine their intent category and risk flags. Intent category: Characterizes the operation type (intent_class) of the executable command, such as read-only diagnostics, package management, network fetch, large-scale file writing, or compilation. Risk flags: Characterizes pre-defined risky operations contained in the executable command, such as detecting high-risk command characteristics like curl, wget, rm-rf, chmod, dd, mkfs, or paths traversing sensitive directories.

[0107] Retrieves a pre-configured configuration template (P_base or base template). This configuration template is used to determine the basic isolation constraints of the isolated execution environment. These basic isolation constraints include at least one of the following: a set of namespaces (such as PID, User, Mount namespaces), a set of system call filters (such as the Seccomp default policy), and a network access policy that defaults to denial (prohibiting all network communication by default). The pre-configured configuration template provides a general security baseline based on the principle of least privilege, ensuring that basic isolation capabilities are guaranteed regardless of the command being executed.

[0108] From a set of pre-defined incremental configuration fragments, a target incremental configuration fragment matching the intent category and risk identifier is selected. This incremental configuration fragment is used to adjust the configuration items corresponding to the intent category and risk identifier based on the basic isolation constraints.

[0109] For example, if the intent category is "DNS resolution required", the corresponding incremental configuration fragment may include a network policy of "enabling UDP / 53 outbound only"; if the intent category is "packet index access required", the corresponding incremental configuration fragment may include a network policy of "enabling HTTPS outbound authorization list"; if the risk identifier includes "large-scale file write", the corresponding incremental configuration fragment may include configurations of "expanding the read-only bind authorization list" or "restricting write operation paths".

[0110] The target incremental configuration fragment is merged into the configuration template to obtain the isolated execution environment configuration information. During this process, if the configuration template and the target incremental configuration fragment conflict for the same configuration item, they are merged according to a preset security priority rule. Specifically, the security priority rule includes: in cases where the conflict involves the relaxation or tightening of access permissions, the tightened configuration item is used to override the relaxed configuration item, resulting in the merged configuration item.

[0111] Relaxed configuration options: These refer to configurations that allow more operations, open more ports, allow more system calls, or allow writing to more paths. For example: allowing access to all TCP ports (a relaxed patch under the default network rejection policy), allowing execution of the execve system call, and allowing writing to the / tmp directory.

[0112] Tightening configuration options: These refer to configurations that restrict operations, close ports, prohibit specific system calls, or restrict write paths. For example: prohibit all network access (base default), prohibit execution of execve (base security policy), and mount / etc for read-only (base security policy).

[0113] In other words, when relaxed and tightened configuration options conflict, the more restrictive option is adopted. This means that even if a command claims to require relaxed permissions to run (e.g., network connectivity), if the base system is tightened by default (e.g., network disconnection by default) and there is no explicit, security-audited authorized list to override it, the relaxation request will be rejected, and the system will remain disconnected.

[0114] Based on the obtained isolated execution environment configuration information, the aforementioned isolated execution environment generation steps are executed (such as creating namespaces, mounting read-only root layers, overlaying temporary writable layers, configuring Seccomp and network policies, etc.), thereby providing an isolated execution environment for executable commands that both meets their business intent (adjusted through incremental fragments) and strictly adheres to security bottom lines (merged through basic templates and security priority).

[0115] In summary, this application's embodiments achieve fine-grained and precise adaptation of isolation permissions through a dynamic policy synthesis process based on intent recognition. This meets diverse operational needs while avoiding the security risks or functional limitations of fixed policies. Combined with the security merging principle of prioritizing tightening in case of conflicts, it ensures that the execution environment always conforms to the security baseline and improves the auditability of policy management and the consistency of execution across multiple backends.

[0116] As some alternative embodiments of this application, before obtaining the executable command, the following steps may also be performed: parsing the preset configuration template during idle periods to obtain the compiled policy handle corresponding to the configuration template; creating a general writable storage layer directory and a temporary file system mount point; and storing the compiled policy handle, the writable storage layer directory, and the temporary file system mount point into the preheating resource pool.

[0117] It should be noted that, in order to reduce the startup latency when executing high-frequency, short-duration custom commands, the following preheating steps can be performed before obtaining executable commands to build a preheating resource pool:

[0118] During idle periods (WarmPool warm-up phase), the pre-configured template is parsed: security constraint information, such as namespace sets, system call filtering sets (Seccomp rules), and network access policies, is extracted. This policy information is then compiled into a form that the operating system kernel can directly recognize or efficiently load, resulting in a compiled policy handle (or seccompBPFfd). This pre-compilation avoids repeated policy parsing and compilation on critical command execution paths, significantly reducing CPU overhead and startup latency.

[0119] Create a generic writable storage layer directory (pre-create an empty upper / workdir directory pool) and temporary file system mount points (pre-allocate temporary file system mount points): Pre-allocate a set of empty directories for use as the temporary writable layer (upper layer) in the sandbox environment. These directories do not contain any data when created, ensuring purity for each use. Pre-plan the file system mount paths to quickly mount the writable storage layer directory to the sandbox environment during command execution.

[0120] The compiled policy handle, general writable storage layer directory, and temporary file system mount point generated above are stored in the warm-up resource pool (or resource pool). When an executable command is obtained, the corresponding resources can be directly retrieved from the warm-up resource pool instead of building from scratch, thus achieving millisecond-level fast startup of the sandbox environment.

[0121] Through the above-mentioned warm-up steps, this embodiment of the application shifts the time-consuming strategy parsing and resource allocation operations from the critical path of command execution to the idle period, which significantly improves the execution efficiency in high-frequency short-time command scenarios, while maintaining the security features of sandbox isolation.

[0122] In some optional embodiments, generating an isolated execution environment based on the isolated execution environment configuration information can be achieved through the following steps: determining whether a compiled policy handle and an idle writable storage layer directory matching the isolated execution environment configuration information exist in the preheating resource pool; if the determination result is yes, performing the following steps: obtaining matching resources from the preheating resource pool, wherein the matching resources include: a compiled policy handle, a writable storage layer directory, and a temporary file system mount point; binding the matching resources with the task identifier of the executable command to obtain the isolated execution environment; if the determination result is no, performing the following steps: parsing the configuration template to obtain the target compiled policy handle corresponding to the executable command; creating the target writable storage layer directory and the target temporary file system mount point corresponding to the executable command; binding the target compiled policy handle, the target writable storage layer directory, and the target temporary file system mount point with the task identifier of the executable command to obtain the isolated execution environment; after executing the executable command, the following steps can also be performed: adding the resources corresponding to the isolated execution environment configuration information to the preheating resource pool.

[0123] It is worth explaining that the process of generating an isolated execution environment based on the configuration information of the isolated execution environment adopts a dual-path scheduling mechanism based on a preheating resource pool, which specifically includes the following steps:

[0124] The system checks if a compiled policy handle and an idle writable storage layer directory matching the isolated execution environment configuration information exist in the preheating resource pool. If they do, the system proceeds to the fast path execution flow: it retrieves the matching resources from the preheating resource pool, including the compiled policy handle, the writable storage layer directory, and the temporary file system mount point. Then, it binds the retrieved matching resources to the task identifier (task_id) of the executable command, thereby quickly generating the isolated execution environment. This process avoids repeated policy parsing and resource creation, significantly reducing execution latency.

[0125] If the determination result is "not found," meaning there is a lack of matching resources in the preheating resource pool, the slow path execution process begins: The configuration template is parsed to obtain the target compiled policy handle corresponding to the executable command. A target writable storage layer directory (upper layer or workdir) and a target temporary file system mount point are created for the executable command. The target compiled policy handle, target writable storage layer directory, target temporary file system mount point, and the task identifier of the executable command are bound together to obtain the isolated execution environment.

[0126] Furthermore, to optimize the execution efficiency of subsequent tasks, after executing the executable command, the resources corresponding to the isolated execution environment configuration information are added to the preheating resource pool. Specifically, the target compiled policy handle, target writable storage layer directory, or target temporary file system mount point (if reuse conditions are met) used during this execution are recycled and stored in the preheating resource pool for direct access by subsequent tasks with the same or similar isolated execution environment configuration information. This mechanism enables hot updating and recycling of resources. As task types accumulate, the hit rate of the preheating resource pool gradually increases, thereby further reducing the overall system startup latency.

[0127] The above steps directly reuse the compiled strategy and storage layer from the preheating pool when resources are hit, which greatly reduces the startup latency of high-frequency commands; and after the task is executed, the resources are backfilled into the preheating pool to realize hot update and recycling of resources, continuously improving the overall execution efficiency.

[0128] In some optional embodiments of this application, before the executable command is executed, the following steps may be performed: calculate the check value of the executable content in the read-only root layer that is within a preset check range to obtain a baseline check value, wherein the preset check range is part or all of the paths in the read-only root layer declared by the isolated execution environment configuration information.

[0129] Furthermore, after the executable command is executed, the following steps can also be performed: recalculate the checksum of the executable content to obtain the verification checksum; compare the verification checksum with the baseline checksum to obtain the integrity check result; if the integrity check result indicates that the verification checksum and the baseline checksum are inconsistent, delete the temporary writable layer and prohibit merging the changed content in the temporary writable layer into the host file system.

[0130] It should be noted that, to ensure that the critical read-only layer of the host file system is not maliciously tampered with or contaminated during command execution, this embodiment performs an integrity baseline construction step before the executable command is executed. Specifically, based on the preset verification range declared in the isolated execution environment configuration information, the executable content under some or all paths in the read-only root layer is selected for integrity verification, and the baseline verification value is calculated. The preset verification range can be a set of critical directories dynamically specified by the sandbox policy, or it can be the entire content of the read-only root layer. Its purpose is to lock the host file state snapshot before execution, providing a reliable benchmark for subsequent integrity comparisons.

[0131] After the executable command is executed, a further integrity verification step is performed to verify the isolation effectiveness of the execution environment. Specifically, the verification value of the executable content within the preset verification range is recalculated to obtain the verification value, and the verification value is compared with the baseline verification value to generate an integrity verification result. This comparison process is used to detect whether, during command execution, there are any unexpected changes to the read-only root layer data caused by mounting errors, permission bypassing, or other attack methods, ensuring that the isolation environment's secrecy is not compromised.

[0132] If the integrity verification result shows that the verified value is inconsistent with the baseline verification value, it is determined that the read-only root layer has suffered integrity corruption during command execution, triggering a mandatory security handling mechanism. This mechanism includes automatically deleting the temporary writable layer to discard all write data generated during this execution, and prohibiting any changes made to the temporary writable layer from being merged or persisted to the host file system. Even if an attacker attempts to contaminate the host's critical system files during sandbox execution, the risk can be identified and the spread of contamination can be blocked in the final stage, thereby ensuring that the final state of the host file system remains consistent with that before execution, meeting compliance requirements in high-security scenarios.

[0133] For example, a checksum can be calculated by performing a comprehensive hash operation on the file system metadata and file content within a preset checksum range to generate an integrity fingerprint with high uniqueness and collision resistance. Specifically, after obtaining the list of paths within the preset checksum range in the read-only root layer, each file or directory entity in the list is traversed. For each entity, its key metadata attributes are read sequentially. These metadata attributes include at least the file content hash value, file inode number, file size, and last modification time (mtime). The file content hash value can be calculated from the actual file data blocks using cryptographic hash algorithms such as SHA-256 or MD5. The metadata can be obtained from the operating system file system interface, reflecting the file's structural state without reading all the file data.

[0134] Furthermore, the obtained file content hash values, inodes, sizes, and mtimes are concatenated into a structured data string according to a preset sorting rule, or input into an aggregate hash function to generate a local checksum for each file entity. A secondary aggregate hash operation is performed on the local checksums of all file entities, or they are sequentially accumulated according to a fixed directory hierarchy, to generate a single baseline checksum (or integrity fingerprint) representing the overall state of the entire preset checksum range. This hierarchical aggregation calculation method not only improves computational efficiency and avoids the performance overhead of reading the entire file, but also ensures that even minor changes in the metadata of a non-critical file in the read-only root layer (such as changes in permission bits or timestamp updates) can be detected and reflected in the checksum, thereby achieving fine-grained monitoring of the integrity of the read-only root layer.

[0135] During the post-command verification phase, the same calculation process is repeated to re-traverse the preset verification range and generate verification values. Since the calculation logic, hash algorithm, and metadata reading method are completely identical to those before execution, any tampering, replacement, or addition of unauthorized files to the underlying data of the read-only root layer will result in a significant difference between the verification value and the baseline verification value. By comparing these two verification values, it is possible to accurately determine whether the read-only root layer has been contaminated with extremely low time complexity, and this determination serves as a key decision-making basis for whether to allow temporary writable layer changes to be merged into the host file system.

[0136] Figure 2 This is a flowchart of another command execution method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0137] Step S201, Strategy analysis and pre-detection.

[0138] Parse the command to be executed and its corresponding sandbox profile; perform a security assessment on the command using a rule engine or lightweight model; if the assessment result does not meet the security threshold, then execute the command or automatically downgrade to a more stringent policy.

[0139] In step S201, a sandbox profile is dynamically selected or synthesized according to the intent of the command (such as read-only diagnostics, packet management, network fetch, etc.), and security assessment and anomaly handling are performed.

[0140] Dynamic policy selection: If the task belongs to the default deployment or a high-frequency, short-term scenario, a strict profile is loaded. This profile is configured in strong isolation mode, disabling network access by default and allowing only minimal system calls. If the task belongs to a scenario that requires executing read-only troubleshooting scripts or writing to a specified log directory, a lenient profile is loaded. This profile is configured with an authorization ticket mechanism, verifying the legitimacy of the business directory through a pre-configured mounted authorization list (rather than hard-coded paths), and appropriately relaxing the call filtering policy (seccomp) and network access control policy to meet business needs while retaining audit requirements.

[0141] Risk Assessment and Degradation: Commands are assessed for security using a rule engine or lightweight model. If the assessment detects a high-risk command (such as one containing sensitive operations like rm-rf or chmod), execution is automatically rejected, or the system automatically switches to a strict profile and forcibly disables network access. If the lightweight model is unavailable, it reverts to rule-based pre-inspection logic to ensure continuity and avoid conflicts between two logics or silent allowance. If the sandbox profile provided by the platform fails to be retrieved, the Agent uses the latest valid version cached locally or executes a security failure policy (i.e., rejects execution). Silent degradation to raw execution is strictly prohibited to ensure that the security baseline is not breached.

[0142] Step S202: Perform environment preparation.

[0143] An isolated execution environment is built on the host machine, including mounting a read-only root layer (lower) and creating a temporary writable layer (upper / workdir, using an overlay file system or equivalent mechanism). Necessary namespace subsets are configured to achieve process and resource isolation; and system call filtering policies (seccomp) and network access control policies are loaded according to the sandbox profile.

[0144] Depending on the selected sandbox profile and execution backend, the specific methods for building the environment include:

[0145] 1. User-space wrapper backend implementation: If bubblewrap (or an equivalent user-space wrapper) is used as the execution backend, the host directory is bound to a read-only root layer in read-only mode using the --ro-bind parameter; the --tmpfs or overlay file system is used as a temporary writable layer; the process ID space is isolated using parameters such as --unshare-pid; for networking, the network namespace can be isolated using --unshare-net, or access can be restricted in combination with the host firewall policy.

[0146] This method does not require a root-privileged daemon process; it can be initiated by the Agent child process and is suitable for high-frequency, short-duration tasks that are sensitive to startup latency.

[0147] 2. Containerized backend implementation: If OCI / runc is used as the execution backend, load a minimized image or a pre-built rootfs as a read-only root layer to ensure the consistency and compliance of the basic environment; use container storage drivers or temporary directories as temporary writable layers.

[0148] This approach is suitable for scenarios with extremely high security requirements and strict adherence to the image baseline. The pre-installation and runtime dependency installation of the image are agreed upon as prerequisites for deployment.

[0149] 3. General configuration: Regardless of the backend used, it is necessary to configure the necessary namespace subset to achieve process and resource isolation; and load the call filtering policy (seccomp) and network access control policy according to the sandbox profile.

[0150] Step S203, executed within the sandbox.

[0151] Execute the command to be executed in the established isolated environment, such as by invoking the shell interpreter (e.g., using the bash -c command), and collect the command's standard output, standard error output, exit code, and optional resource consumption metrics and security event logs in real time.

[0152] During this process, the strategy is dynamically adjusted or security events are recorded based on real-time feedback during execution (such as network request characteristics); in the case of a lenient profile scenario, necessary write operations are allowed in the business directories within the pre-configured authorized list, and relevant audit logs are recorded.

[0153] Step S204, finalization, temporary layer is discarded by default.

[0154] Perform the default discard operation, which directly deletes the temporary writable layer and ensures that its contents are not merged back into the host file system; Figure 3 This is a timing diagram illustrating a read-only root, a temporary writable layer, and a discard layer according to an embodiment of this application, demonstrating the timing logic.

[0155] In step S204, the following security checks and procedures are performed.

[0156] 1. Integrity verification: Before discarding or submitting, calculate the integrity fingerprint (including the comparison between the baseline fingerprint and the verification fingerprint) of the content in the read-only root layer that is within the preset verification range.

[0157] If the read-only root layer is found to be contaminated (i.e., the verification fingerprint is inconsistent with the baseline fingerprint), the temporary writable layer is forcibly discarded and commits are prohibited to ensure the security of the host file system.

[0158] 2. Commit Auditing: Changes to the temporary writable layer are only allowed to be persisted (committed) to the host if explicit authorization conditions are met and post-event audit checks are passed. For changes requiring persistence, a metadata-only analysis is performed to generate a change list, ensuring that critical system files (such as / etc / passwd, / etc / shadow, etc.) have not been modified, and that intent compliance checks are passed (e.g., confirming that the write path is within the commit authorization list) before committing. If the compliance check fails, discarding is automatically executed, and discard_forced_by_policy=true is set.

[0159] Step S205: Result encapsulation and reporting.

[0160] Construct a task execution result object, which contains command execution result data and extended metadata fields. The extended metadata fields include at least: sandbox policy identifier (sandbox_profile_id), policy version number (policy_version), layer identifier (layer_id) or discard flag (discardflag), and execution backend type; send the result back to the platform through the existing task result transmission channel, where the command content is stored in the unified parameter field and the sandbox metadata is stored in the extended fields.

[0161] In step S205, the execution result is encapsulated and reported.

[0162] 1. Metadata integrity: The results must include task_type, task_id, execution_no, agent_id, and sandbox metadata for the platform to perform full-chain queries and audits.

[0163] 2. Failure Stage Reporting: If any stage—pre-check, preparation, execution, or cleanup—fails (e.g., policy retrieval failure, environment preparation timeout), the system will report the specific failure stage and its cause code in the results. If policy retrieval fails, the system will record the status of using the locally cached version or the execution being refused, ensuring no silent degradation.

[0164] Figure 4 This is a schematic diagram illustrating a Profile mapping with dual backends and task result field expansion according to an embodiment of this application, as shown below. Figure 4 As shown, Figure 4 It clearly demonstrates how the sandbox profile is mapped to different execution backends (such as bubblewrap or OCI / runc), as well as the structure and expansion methods of various metadata fields in the task results (such as sandbox_profile_id, policy_version, backend_type, etc.).

[0165] Figure 5 This is a structural diagram of a command execution device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0166] The first acquisition module 51 is used to acquire executable commands, determine the configuration information of the isolated execution environment corresponding to the executable commands, and perform a security assessment on the executable commands to obtain the assessment results.

[0167] The generation module 52 is used to generate an isolated execution environment based on the configuration information of the isolated execution environment, provided that the evaluation result characterization meets the preset security policy. The isolated execution environment includes at least: a read-only root layer and a temporary writable layer; the read-only root layer is built on the host file system and is used to provide a read-only file system for the execution of executable commands; the temporary writable layer is used to carry the write data generated by the executable commands during the execution process.

[0168] The second acquisition module 53 is used to execute executable commands in an isolated execution environment and acquire the output data and exit codes of the executable commands.

[0169] The determination module 54 is used to determine the processing result for the temporary writable layer after executing the executable command. The processing result includes: deleting the temporary writable layer if the preset authorization conditions are not met; and merging the changed content in the temporary writable layer into the host file system if the preset authorization conditions are met.

[0170] The encapsulation module 55 is used to encapsulate the output data, exit code, and processing result, and send the encapsulation result to the sending object of the executable command.

[0171] It should be noted that the above Figure 5 The modules in can be program modules (e.g., a set of program instructions that implements a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0172] It should be noted that, Figure 5 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0173] Figure 6 A hardware block diagram of a computer terminal for implementing a command execution method is shown. Figure 6As shown, the computer terminal 60 may include one or more processors (shown as 602a, 602b, ..., 602n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 604 for storing data, and a transmission module 606 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 6 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, the computer terminal 60 may also include... Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown.

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

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

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

[0177] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 60.

[0178] It should be noted here that, in some optional embodiments, the above... Figure 6 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 6 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0179] It should be noted that, Figure 6 The computer terminal shown is used to execute Figure 1 The execution method of the command shown above also applies to this electronic device, and will not be repeated here.

[0180] This application also provides a non-volatile storage medium, which includes a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above-mentioned command execution method.

[0181] A program that performs the following functions on a non-volatile storage medium: acquires an executable command, determines the configuration information of the isolated execution environment corresponding to the executable command, performs a security assessment on the executable command, and obtains the assessment result; if the assessment result indicates that the preset security policy is met, generates an isolated execution environment based on the isolated execution environment configuration information, wherein the isolated execution environment includes at least: a read-only root layer and a temporary writable layer; the read-only root layer is built on the host file system and is used to provide a read-only file system for the execution of the executable command; the temporary writable layer is used to carry the write data generated by the executable command during execution; executes the executable command within the isolated execution environment and acquires the output data and exit code of the executable command; after executing the executable command, determines the handling result for the temporary writable layer, wherein the handling result includes: deleting the temporary writable layer if the preset authorization conditions are not met; merging the changes in the temporary writable layer into the host file system if the preset authorization conditions are met; encapsulating the output data, exit code, and handling result, and sending the encapsulation result to the sending object of the executable command.

[0182] This application also provides an electronic device, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-mentioned command execution method when it runs.

[0183] The processor runs a program that performs the following functions: acquires an executable command, determines the configuration information of the isolated execution environment corresponding to the executable command, performs a security assessment on the executable command, and obtains the assessment result; if the assessment result indicates that the preset security policy is met, it generates an isolated execution environment based on the isolated execution environment configuration information, wherein the isolated execution environment includes at least: a read-only root layer and a temporary writable layer; the read-only root layer is built based on the host file system and is used to provide a read-only file system for the execution of the executable command; the temporary writable layer is used to carry the write data generated by the executable command during execution; executes the executable command within the isolated execution environment and acquires the output data and exit code of the executable command; after executing the executable command, it determines the handling result for the temporary writable layer, wherein the handling result includes: if the preset authorization conditions are not met, deleting the temporary writable layer; if the preset authorization conditions are met, merging the changed content in the temporary writable layer into the host file system; encapsulating the output data, exit code, and handling result, and sending the encapsulation result to the sending object of the executable command.

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

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

[0186] In the above embodiments of this application, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, take necessary protective measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

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

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

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

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

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

Claims

1. A method for executing a command, characterized in that, include: Obtain the executable command, determine the isolated execution environment configuration information corresponding to the executable command, and perform a security assessment on the executable command to obtain the assessment result; If the evaluation results indicate that the preset security policy is met, an isolated execution environment is generated according to the isolated execution environment configuration information. The isolated execution environment includes at least: a read-only root layer and a temporary writable layer; the read-only root layer is built based on the host file system and is used to provide a read-only file system for the execution of the executable command; the temporary writable layer is used to carry the write data generated by the executable command during execution. Execute the executable command within the isolated execution environment, and obtain the output data and exit code of the executable command; After executing the executable command, the processing result for the temporary writable layer is determined, wherein the processing result includes: deleting the temporary writable layer if the preset authorization conditions are not met; and merging the changed content in the temporary writable layer into the host file system if the preset authorization conditions are met. The output data, the exit code, and the processing result are encapsulated, and the encapsulation result is sent to the sending object of the executable command. Based on the isolated execution environment configuration information, an isolated execution environment is generated, including: determining the intent category and risk identifier of the executable command, wherein the intent category is used to characterize the operation type of the executable command, and the risk identifier is used to characterize the preset risk operation contained in the executable command; obtaining a preset configuration template, wherein the configuration template is used to determine the basic isolation constraints of the isolated execution environment, the basic isolation constraints including at least one of the following: a namespace set, a system call filter set, and a network access policy that is denied by default; and determining a target incremental configuration that matches the intent category and the risk identifier from a plurality of preset incremental configuration fragments. The configuration fragment is configured to adjust configuration items corresponding to the intent category and the risk identifier based on the basic isolation constraints. The target incremental configuration fragment is then merged into the configuration template to obtain the isolated execution environment configuration information. When the configuration template and the target incremental configuration fragment conflict for the same configuration item, they are merged according to a preset security priority rule. This security priority rule includes: if the conflict involves the relaxation or tightening of access permissions, the tightened configuration item is used to cover the relaxed configuration item, resulting in a merged configuration item. An isolated execution environment is then generated based on the isolated execution environment configuration information.

2. The method according to claim 1, characterized in that, The isolated execution environment further includes: namespace isolation configuration, system call filtering policy, and network access control policy; based on the isolated execution environment configuration information, an isolated execution environment is generated, including: The host file system is mounted to the child process in a read-only binding manner to obtain the read-only root layer, wherein the child process is a process initiated by the agent to carry the isolated execution environment; The temporary writable layer is created within the subprocess and superimposed on the read-only root layer, so that the contents of the read-only root layer can be accessed in read-only mode, and the write data generated during the execution process is written to the temporary writable layer. Based on the namespace selection option in the isolated execution environment configuration information, the process namespace of the child process is isolated to obtain the namespace isolation configuration; Based on the system call filtering items in the isolated execution environment configuration information, the system call filtering policy is loaded for the child process. The system call filtering policy is used to allow the child process to initiate system calls within a preset range and to block system calls outside the preset range, based on the system call filtering items. Based on the network control items in the isolated execution environment configuration information, the network namespace of the child process is isolated, or firewall rules are configured for the child process to obtain the network access control policy.

3. The method according to claim 2, characterized in that, The isolated execution environment configuration information also includes: a mount permission list and a controlled access identifier, wherein the mount permission list is a pre-configured set of host directories that are allowed to be bound and mounted to the isolated execution environment; the controlled access identifier is used to indicate whether the execution of the executable command requires approval; Based on the isolated execution environment configuration information, an isolated execution environment is generated, including: binding and mounting the host directory in the host file system that matches the mount permission list to the isolated execution environment according to the mount permission list; configuring the system call range allowed by the system call filtering policy according to the system call filtering item in the isolated execution environment configuration information; and configuring the network access range allowed by the network access control policy according to the network control item in the isolated execution environment configuration information. Executing the executable command within the isolated execution environment includes: obtaining an approval result for the executable command if the controlled access identifier indicates that approval is required; and executing the executable command if the approval result indicates that the approval is successful.

4. The method according to claim 1, characterized in that, Based on the isolated execution environment configuration information, an isolated execution environment is generated, including: Determine the pre-configured container image corresponding to the isolated execution environment configuration information, wherein the container image includes: the root file system required for the executable command to run; The container image is loaded in read-only mode to obtain the read-only root layer; Create a container storage layer or temporary directory as the temporary writable layer, and overlay the temporary writable layer on top of the read-only root layer, so that the write data generated by the executable command during execution is written to the temporary writable layer, and the container image remains read-only; After executing the executable command, the processing result for the temporary writable layer is determined, including: The temporary writable layer is processed by deleting the container storage layer or temporary directory corresponding to it, and the processing result is obtained.

5. The method according to claim 1, characterized in that, A security assessment is performed on the executable command to obtain the assessment results, including: If a preset evaluation model is available, the executable command is evaluated for security using the preset evaluation model to obtain the evaluation result. If the preset evaluation model is unavailable, a preset rule table is used to perform a security evaluation on the executable command to obtain the evaluation result; wherein, the evaluation result includes the risk level of the executable command; both the preset evaluation model and the preset rule table use the same configuration switching logic to determine the isolated execution environment configuration information corresponding to the executable command; After performing a security assessment on the executable command and obtaining the assessment result, the method further includes: If the risk level is greater than or equal to a preset risk threshold, the executable command will be refused to be executed, or the isolation execution environment configuration information corresponding to the executable command will be switched to a preset enhanced isolation configuration. The system call range allowed by the enhanced isolation configuration is smaller than the system call range allowed before the switch, and the network control item in the enhanced isolation configuration indicates that the execution process of the executable command is prohibited from accessing the network.

6. The method according to claim 1, characterized in that, Before obtaining the executable command, the method further includes: During idle periods, the preset configuration template is parsed to obtain the compiled policy handle corresponding to the configuration template; Create a generic writable storage layer directory and a temporary file system mount point; The compiled policy handle, the writable storage layer directory, and the temporary file system mount point are stored in the preheating resource pool.

7. The method according to claim 6, characterized in that, Based on the isolated execution environment configuration information, an isolated execution environment is generated, including: Determine whether there is a compiled policy handle and an idle writable storage layer directory in the preheating resource pool that match the isolated execution environment configuration information; If the determination result is that it exists, the following steps are performed: obtain the matching resource from the preheating resource pool, wherein the matching resource includes: the compiled policy handle, the writable storage layer directory, and the temporary file system mount point; bind the matching resource with the task identifier of the executable command to obtain the isolated execution environment; If the determination result is that it does not exist, the following steps are performed: the configuration template is parsed to obtain the target compiled policy handle corresponding to the executable command; the target writable storage layer directory and the target temporary file system mount point corresponding to the executable command are created; the target compiled policy handle, the target writable storage layer directory, the target temporary file system mount point are bound to the task identifier of the executable command to obtain the isolated execution environment; After executing the executable command, the method further includes adding the resources corresponding to the isolated execution environment configuration information to the preheating resource pool.

8. The method according to claim 1, characterized in that, Before the executable command is executed, the method further includes: calculating the verification value of executable content within a preset verification range in the read-only root layer to obtain a baseline verification value, wherein the preset verification range is part or all of the paths in the read-only root layer as declared by the isolated execution environment configuration information; After the executable command is executed, the method further includes: recalculating the check value of the executable content to obtain a verification check value; comparing the verification check value with the baseline check value to obtain an integrity check result; and deleting the temporary writable layer and prohibiting the merging of changes in the temporary writable layer into the host file system when the integrity check result indicates that the verification check value and the baseline check value are inconsistent.

9. A command execution device, characterized in that, include: The first acquisition module is used to acquire an executable command, determine the isolated execution environment configuration information corresponding to the executable command, and perform a security assessment on the executable command to obtain the assessment result. A generation module is used to generate an isolated execution environment based on the isolated execution environment configuration information, provided that the evaluation result indicates that the preset security policy is met. The isolated execution environment includes at least a read-only root layer and a temporary writable layer. The read-only root layer is built on the host file system and is used to provide a read-only file system for the execution of the executable command. The temporary writable layer is used to carry the write data generated by the executable command during execution. The second acquisition module is used to execute the executable command within the isolated execution environment and acquire the output data and exit code of the executable command; The determination module is used to determine the processing result for the temporary writable layer after executing the executable command, wherein the processing result includes: deleting the temporary writable layer if the preset authorization conditions are not met; and merging the changed content in the temporary writable layer into the host file system if the preset authorization conditions are met. The encapsulation module is used to encapsulate the output data, the exit code, and the processing result, and send the encapsulation result to the sending object of the executable command; The generation module is further configured to perform the following steps: determine the intent category and risk identifier of the executable command, wherein the intent category is used to characterize the operation type of the executable command, and the risk identifier is used to characterize the preset risk operation contained in the executable command; obtain a preset configuration template, wherein the configuration template is used to determine the basic isolation constraints of the isolated execution environment, the basic isolation constraints including at least one of the following: a namespace set, a system call filter set, and a network access policy that is denied by default; determine a target incremental configuration fragment that matches the intent category and the risk identifier from a plurality of preset incremental configuration fragments, wherein... In this process, the incremental configuration fragment is used to adjust the configuration items corresponding to the intent category and the risk identifier based on the basic isolation constraints; the target incremental configuration fragment is merged into the configuration template to obtain the isolated execution environment configuration information; wherein, when the configuration template and the target incremental configuration fragment conflict for the same configuration item, they are merged according to a preset security priority rule, the security priority rule including: when the conflict involves the relaxation and tightening of access permissions, the tightened configuration item is used to cover the relaxed configuration item to obtain the merged configuration item; and an isolated execution environment is generated according to the isolated execution environment configuration information.

10. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the method of executing commands as described in any one of claims 1 to 8.

11. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, the device containing the non-volatile storage medium executes the command execution method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for executing the command as described in any one of claims 1 to 8.

Images