A software patch security execution method and system based on container isolation

Abstract

The application relates to the field of software security, and particularly discloses a software patch security execution method and system based on container isolation. The following steps are realized through Go language: receiving a target software path and a patch file path; creating a temporary container environment, mounting a software directory in a read-only mode, and mounting a patch file in an executable form; running a network monitoring module on a host computer, adopting transparent proxy to intercept all network requests of a patch program in the container, and prompting a user to make a decision in real time; executing a predefined function test script in the container, verifying the integrity of core functions through weighted calculation, and synchronizing modified files in the container to a target directory of the host computer if the function test is passed and no network request is blocked, otherwise automatically destroying the container. The method can effectively solve the security risks and environmental pollution problems of patch application by isolating malicious codes through containers, dynamically monitoring network behaviors, and automatically verifying the integrity of functions.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software security, in particular to a software patch security execution method and system based on container isolation. BACKGROUND

[0002] With the continuous growth of the complexity and deployment scale of software systems, software patch management has become a key link in maintaining system security and functional integrity. Patch programs are usually used to fix security vulnerabilities, functional defects or improve performance, but the patch application process itself may introduce new security risks and stability problems. The existing technology mainly has the following technical problems to be solved:

[0003] Malicious attackers may implant backdoors, ransomware or data theft code by tampering with patch programs; uncontrolled network behavior caused by data leakage problems during patch execution; functional failures caused by patch compatibility defects; software core function anomalies caused by patches, such as key business process interruption, data calculation logic error or memory leakage; and unpredictable errors caused by software in a semi-updated state due to partial modified files or configurations left by failed patch installation.

[0004] In view of the above problems, we design a software patch security execution method and system based on container isolation to solve the above problems. SUMMARY

[0005] The purpose of the present application is to solve the system risks caused by malicious patches, data leakage caused by uncontrollable network behavior, functional failures caused by patch compatibility defects, and software in a semi-updated state caused by partial residues left by failed patch installation in the prior art. A software patch security execution method and system based on container isolation are proposed. The technical solution dynamically controls risks in the execution phase, suppresses malicious code diffusion through lightweight environment isolation, blocks unauthorized communication through interactive network monitoring, ensures functional integrity through an automated verification mechanism, and eliminates modification residues through transient environment destruction.

[0006] In order to achieve the above purpose, the present application adopts the following technical solutions:

[0007] A software patch security execution method based on container isolation, comprising the following steps:

[0008] Step S1, receiving a target software installation path and a patch program file path;

[0009] Step S2, creating a temporary container environment and mounting a directory;

[0010] Step S3, running the network monitoring module when executing the patch program in the container to intercept the request;

[0011] Step S4, running the target software in the container, executing the function test script predefined by the automation verification module, verifying the software function, and judging the core function of the software;

[0012] Step S5, deciding whether to synchronize the file according to the verification result and the network behavior.

[0013] Further, in step S2, the container management interface is called by using Go language to create a temporary container environment, and the installation directory of the target software is mounted to the first path of the container in a read-only manner, and the patch program is mounted to the second path of the container in the form of an executable file; the temporary container environment is configured to prohibit persistent storage, and is automatically destroyed after the container exits; the steps of creating the temporary container environment are as follows:

[0014] Step S21, using the os / exec package of Go language to call the Docker command line tool or using the DockerSDK of Go language to create a container;

[0015] Step S22, configuring an independent network namespace for the container;

[0016] Step S23, starting a daemon process in the container, which is used to receive the execution command sent by the host;

[0017] Further, in step S3, when executing the patch program in the container, a network monitoring module written by Go language is also run on the host, and the network monitoring module intercepts all network requests of the patch program in the container by creating a transparent proxy;

[0018] When the network monitoring module detects a network request, the request is paused, and a dialog box is displayed to the user, prompting the user to select allow or block; the processing function of the network request is:

[0019] ;

[0020] Among them, represents the processing request function, represents the output as allow, represents the output as block; represents the network request.

[0021] Further, creating a transparent proxy includes the following steps:

[0022] Step S31, using the net package and gopacket library in Go language to listen to raw network packets on the host;

[0023] Step S32, redirect the container's outbound traffic to the port that the proxy program listens to by configuring iptables rules;

[0024] Step S33, the proxy program parses and extracts the target address, source address, port and data content after receiving the redirected traffic;

[0025] Step S34, the information is displayed on the user interaction interface, and according to the user's selection, the network request is released or intercepted by the proxy program.

[0026] Further, in step S4, the target software is run in the container, and the pre-defined function test script is executed by the automatic verification module written in Go language to determine whether the core function of the target software is running normally. The expression of the function of the software verified by the automatic verification module after the patch is as follows:

[0027] ;

[0028] Among them, represents the verification result, represents success, represents failure, represents the total number of test items, represents the weight of the th test item, represents the result of the th test item; represents a preset threshold.

[0029] Further, the pre-defined function test script executed by the automatic verification module written in Go language includes:

[0030] Step S41, start the target software and execute the key operation sequence;

[0031] Step S42, capture the output log of the target software, use the regexp package in Go language for regular matching, and check whether it contains the expected success pattern;

[0032] Step S43, check the state of the control on the interface of the target software, and obtain the state information through OCR or automatic test tool.

[0033] Further, in step S5, according to the verification result and the network behavior, it is determined whether to synchronize the file. If the function verification is successful and the user does not block any network request, the file modified by the patch in the container is copied to the target software installation directory of the host; otherwise, all changes in the container are discarded.

[0034] Further, copying the file modified by the patch in the container to the target software installation directory of the host includes:

[0035] Step S51, using Go language to traverse the target software installation directory in the container, calculate the hash value of the file and compare it with the original file to get the modified file list;

[0036] Step S52, only the files in the modified file list are extracted to the host temporary directory through the container export function;

[0037] Step S53, running the automated verification module to verify the exported file on the host original software application, and covering the original file after verification.

[0038] A system applied to a software patch safe execution method based on container isolation, the system comprises:

[0039] A user interface module receives the target software installation path and patch program file path specified by the user;

[0040] A container management module is realized by Go language, used for creating and managing temporary container environment;

[0041] A network monitoring module is realized by Go language, used for intercepting and displaying network requests, and waiting for user decision;

[0042] An automated verification module is realized by Go language, used for executing predefined function test scripts to verify the function of the patched software;

[0043] A file synchronization module is realized by Go language, used for synchronizing the modified files in the container to the host.

[0044] Further, the system further comprises a whitelist management module for storing known safe patch program features, the patch program features comprising:

[0045] File hash value, destination address and port of network request;

[0046] When the characteristics of the patch program match the records in the whitelist, the network request is automatically allowed, and the user confirmation step is skipped.

[0047] Compared with the prior art, the beneficial effects of the present application are: the present application uses container isolation technology to limit the execution environment of the patch program, configures independent network namespace to realize complete isolation, monitors network requests in real time through transparent proxy and supports user decision, combines with automated verification mechanism to ensure function integrity, and finally synchronizes the modified files only after verification, has the advantages of effectively isolating potential malicious patch program, dynamically monitoring network behavior, automatically verifying function integrity and eliminating modification residues. BRIEF DESCRIPTION OF DRAWINGS

[0048] Figure 1A flowchart of a software patch secure execution method based on container isolation is provided in the present application;

[0049] Figure 2 A flowchart of the creation of an isolated container in a software patch secure execution method based on container isolation is provided in the present application;

[0050] Figure 3 A flowchart of network monitoring in a software patch secure execution method based on container isolation is provided in the present application;

[0051] Figure 4 A flowchart of file synchronization in a software patch secure execution method based on container isolation is provided in the present application. DETAILED DESCRIPTION

[0052] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application.

[0053] Traditional antivirus solutions rely on static signature detection, and have limited protection capabilities for new or unknown malicious patches. When a patch is executed directly in the host operating system environment, malicious code can access the file system, registry and sensitive data of the host computer unrestrictedly, causing systematic intrusion, which is particularly serious in critical business systems.

[0054] The problem of data leakage caused by uncontrollable network behavior needs to be solved urgently. When a patch program is executed, it may initiate unannounced network connections, including leaking system environment information to external servers, downloading unverified additional components, or establishing a reverse Shell connection to accept remote instructions. Standard firewalls can only perform coarse-grained control based on ports / IP, and cannot dynamically intercept and prompt the user for decision-making when the program is executed, making it difficult to effectively control the potential data leakage risk.

[0055] Patches may cause abnormal software core functions, such as interruption of critical business processes, data calculation logic errors, or memory leakage, etc. Enterprises usually rely on manual testing to verify patch stability, which takes a long time of several hours to several days. Existing automated testing tools lack deep integration with the patch deployment process, and cannot achieve a "deployment-verification-rollback" closed loop, resulting in delayed problem discovery.

[0056] Failed patch installation may leave partially modified files or configurations, causing the software to be in a semi-updated state and triggering unpredictable errors, or leaving files that interfere with subsequent patch application. Traditional virtualization technology requires complete cloning of system images, which consumes a lot of resources and starts slowly, making it difficult to meet the agility requirements of patch verification.

[0057] The above software patch management faces the risks of malicious code spreading, data leakage, function abnormality and environment residue. The traditional antivirus solution relies on static detection and cannot cope with unknown malicious patches; the standard firewall can only perform coarse-grained control based on ports / IP; manual testing and verification is time-consuming; and the virtualization technology consumes a lot of resources and starts slowly. For example, when a certain enterprise applies a patch, malicious code leaks sensitive data through an undeclared network connection, and the traditional protection means cannot dynamically intercept such requests.

[0058] It is necessary to build an isolated environment to block the spread of malicious behavior, and at the same time establish a dynamic monitoring mechanism to control network behavior. Through analysis, it is found that container technology can provide lightweight isolation, but the problem of file interaction between the container and the host machine needs to be solved; transparent proxy can capture network traffic, but it needs to be combined with a user decision mechanism; automated testing needs to be deeply integrated with container deployment to achieve rapid verification. Based on this, the technical idea of combining container isolation, network monitoring and automated verification is formed.

[0059] Therefore, the software patch security execution method based on container isolation is proposed in the embodiment, with reference to Figure 1 The method is implemented in the following way.

[0060] Step S1, receiving the target software installation path and the patch program file path;

[0061] Step S2, creating a temporary container environment (isolated container) and mounting a directory;

[0062] Step S3, running a network monitoring module to intercept requests when executing the patch program in the container;

[0063] Step S4, running the target software in the container, executing the function test script predefined by the automated verification module, verifying the software function, and judging the core function of the software;

[0064] Step S5, deciding whether to synchronize files according to the verification result and network behavior.

[0065] The temporary container environment refers to a transient running environment created through a container management interface, which can be implemented by using a Docker SDK, and the temporary container environment is automatically destroyed after the container exits, and is used to isolate the direct impact of the patch program on the host. The network monitoring module refers to a module component for capturing network traffic through a transparent proxy, which can be implemented by using a gopacket library to analyze data packets and by using iptables rules to realize traffic redirection, and is used to dynamically control the network behavior of the patch program. The automatic verification module refers to a module component for executing a pre-defined function test script, which can be implemented by using a regular expression to match log information, and is used to quickly verify the function integrity of the patched software. The file synchronization mechanism refers to a process for selectively copying modified files after verification, which can be implemented by using a hash value to identify changed files, and is used to ensure synchronization of only effective modifications.

[0066] As shown in Figure 2 Step S2, a container management interface (Docker interface) is called by using a Go language, when a user specifies a receiving target software installation path and a patch program file path, the system creates a temporary container environment and sets a mounting configuration, the target software directory is mounted to a first path of the container in a read-only manner, and the patch program is mounted to a second path of the container in an executable file form. The temporary container environment is configured to prohibit persistent storage, and is automatically destroyed after the container exits.

[0067] The specific steps for creating the temporary container environment include:

[0068] Step S21, the host calls the Docker interface, a Docker command line tool is called by using an os / exec package of the Go language, or a temporary container environment (isolated container) is created by using a Docker SDK of the Go language;

[0069] Step S22, an independent network namespace (mounting configuration) is configured for the container;

[0070] Step S23, a lightweight daemon process is started in the container, and an execution command (network policy) sent by the host is received.

[0071] The os / exec package of the Go language calls the Docker command line tool, which means operating the container by executing system commands. Specifically, the exec.Command function can be used to build the Docker run instruction to achieve this, and this method is compatible with different versions of container runtime environment. The Docker SDK of the Go language refers to directly calling the programming interface provided by the container engine. Specifically, the ContainerCreate method can be implemented by initializing the client object. This method can accurately control the container configuration parameters. The network strategy adopted is: an independent network namespace refers to allocating an independent network protocol stack for the container. Specifically, the none mode can be set through the --network parameter of Docker to achieve this feature, which makes the container unable to directly access the external network. A lightweight daemon refers to a resident service program running in the container. Specifically, a binary file compiled by the Go language can be used to listen to the Unix domain socket. This process is responsible for parsing and executing the patch installation instructions sent by the host.

[0072] When receiving the patch execution request input by the user, the container management module selects to call the Docker command line tool or the SDK interface according to the host environment. For example, in the development and test environment, the exec package can be used to execute the "docker run -v / host / path: / container / path:ro" command to create an isolated environment. In the production environment, the NewClientWithOpts method of the Docker SDK is used to establish a connection, and the ContainerCreate interface is called to configure the read-only mounting parameter. When the container starts, an independent network space is created by setting the NetworkMode to "none" to block unauthorized network communication. The daemon running in the container listens to the control instruction through the file descriptor. For example, when receiving the patch execution command sent by the host, the patch program is triggered to run in the isolated environment.

[0073] Traditional virtualization technology needs to completely clone the operating system image. For example, VMware usually needs to allocate fixed disk space and load the complete kernel when creating a virtual machine, which results in high resource occupation and more than 60 seconds of startup time. The present scheme realizes process-level isolation through container technology. For example, the startup time of the Docker container can be shortened to 2 seconds, and the memory occupation is only 5%-10% of the host. In the prior art, the container network usually adopts the bridge mode, which has a potential network attack surface. The setting of the independent network namespace completely cuts off the connection channel between the container and the external network.

[0074] As Figure 3As shown, in step S3, the patch program is executed in the container while the network monitoring module written in Go language is running on the host machine, and the network monitoring module intercepts all network requests of the patch program in the container by creating a transparent proxy. The network monitoring module on the host machine intercepts all outbound requests in real time and prompts the user for decision. For example, when the patch attempts to connect to an unknown server, the network monitoring module detects the network request, the system pauses the network request, and a dialog box is displayed to the user, prompting the user to select allow or block.

[0075] The processing function of the network request is:

[0076] ;

[0077] wherein, represents the processing request function, represents the output as allow, represents the output as block; represents the network request; the trust list is pre-configured by the user.

[0078] At the same time, the automated verification module runs the test script in the container, and judges whether the core function meets the standard through weighted calculation. If the function verification is successful and no network request is blocked, the system synchronizes the modified files in the container to the host machine, otherwise the container environment is automatically destroyed.

[0079] The traditional scheme needs several minutes of startup time for patch testing in a complete virtualization environment, while the present method can complete environment preparation in seconds using container technology. Existing firewalls can only filter traffic based on preset rules, while the present method realizes dynamic control through transparent proxy and user interaction. Conventional testing tools are independent of the deployment process, while the present method deeply integrates automated verification into the container execution process.

[0080] The specific method for creating a transparent proxy is:

[0081] Step S31, using the net package and gopacket library in Go language to listen to raw network packets on the host machine;

[0082] Step S32, redirect the outbound traffic of the container to the port listened by the proxy program by configuring iptables rules;

[0083] Step S33, after receiving the redirected traffic, the proxy program parses and extracts the target address, source address, port and data content;

[0084] Step S34, display the above information on the user interaction interface; according to the user's selection, the network request is released or intercepted by the proxy program.

[0085] The listening of the original network packet refers to capturing the unprocessed network communication data through the underlying network interface provided by the operating system. Specifically, the net package of the Go language can be used to establish an original socket, and the gopacket library can be used for protocol analysis, thereby realizing full monitoring of the network behavior of the patch program in the container. The configuration of the iptables rule refers to modifying the network traffic routing strategy by using the packet filtering system of the Linux kernel. Specifically, the NAT table rule can be added by executing the iptables command to forward the egress traffic of the specified container to the local port listened by the proxy program, ensuring that all outgoing requests must pass through the proxy for review. The parsing and extraction of the target address refer to separating the communication quintuple and payload content from the IP header and transport layer header of the network packet. Specifically, the Layer analysis function of the gopacket library can be used to peel off the Ethernet frame, IP packet, and TCP / UDP segment layer by layer to extract the key fields for subsequent decision-making and judgment. The user interaction interface refers to a graphical or command-line request approval terminal. Specifically, the GUI library or web framework of the Go language can be used to build a real-time request list display interface, with each request accompanied by the target address, port, and data digest, waiting for user confirmation.

[0086] When the patch program in the container attempts to establish a network connection, the egress packet is first received by the host network card. Through the preconfigured iptables rule, these packets are redirected to the local port listened by the proxy program. After the proxy program captures the packet using the original socket, it uses the protocol analysis library to peel off the packet header layer by layer, extracts the target IP, port, protocol type, and the first 128 bytes of the payload as digest information, and judges whether it matches the preset trusted patch feature data whitelist loaded in the system initialization phase. If it matches, it is automatically released directly; if it does not match, these information is pushed to the user interface in real time to display the detailed parameters of the request in a readable form. The user can decide to release or block according to whether the target address belongs to the preset trusted list, and the proxy program implements traffic forwarding or discarding by rewriting the target address of the packet according to the instructions.

[0087] The traditional firewall solution can only filter ports or IP addresses based on static rules and cannot dynamically capture and review the specific network request content during program execution. However, the transparent proxy and interactive approval mechanism of the present solution can not only identify non-declared addresses that the patch program attempts to connect to, but also capture potential data transmission behaviors, such as sending encrypted packets to unrecorded servers.

[0088] In step S4, the target software is run in the container, and the automatic verification module written in Go language executes the pre-defined function test script to verify the software function and determine whether the core function of the target software is running normally. The expression of the automatic verification module verifying the function of the patched software is as follows:

[0089] ;

[0090] wherein, represents the verification result, represents success, represents failure, represents the total number of test items, represents the weight of the th test item, represents the result of the th test item (1 for pass, 0 for failure); represents the preset threshold value.

[0091] The function test script executed by the automatic verification module includes:

[0092] Step S41, starting the target software and executing a key operation sequence;

[0093] Step S42, capturing the output log of the target software, using the regexp package in Go language for regular matching, checking whether it contains the expected success pattern;

[0094] Step S43, checking the state of a specific control on the interface of the target software, obtaining the state information through OCR or an automated test tool.

[0095] wherein, the function test script refers to a set of operation instruction sequences for verifying the core functions of the software, which can be implemented by using simulated operation steps based on key business processes, such as executing operations such as query, insertion, transaction rollback, etc. in the database patch. Regular matching refers to pattern recognition of log content through a predefined regular expression pattern, which can be implemented by using the FindString or MatchString method of the regexp package, such as searching for success identifiers such as “transaction committed successfully” in the log. OCR or automated test tool refers to a technical means for obtaining the state of a graphical interface control, which can be implemented by using the Tesseract OCR engine to parse the text in the interface screenshot, or by using Selenium WebDriver to obtain the enabled, visible attribute values of the control.

[0096] The automation verification module first performs key operations of the software in a predefined order, such as simulating page loading, form submission, plug-in calling and other processes in the browser patch. The logs generated during the operation process are captured in real time and scanned line by line through a regular expression matching engine to detect whether there are keywords matching the success mode. At the same time, the interface state detection module obtains the state of specific UI elements through screenshot or control tree traversal, such as checking whether the "save" button is in a clickable state or whether the progress bar reaches 100%. When the execution results of all test items meet the expectations, it is determined that the function verification is passed.

[0097] Traditional manual testing requires operators to execute test cases step by step and observe the results with the naked eye, which is easy to miss or cause subjective judgment deviation, resulting in insufficient verification. The combination verification method based on regular expressions and automation tools can achieve objective detection of full-process coverage, such as accurately matching transaction submission status codes in logs through regular expressions, avoiding omissions that may occur when manually checking massive logs.

[0098] Reference Figure 4 The application further proposes that in step S5, it is decided whether to synchronize files according to the verification result and network behavior. If the function verification is successful and the user does not block any network request, the files modified by the patch in the container are copied to the target software installation directory of the host machine; otherwise, all changes in the container are discarded.

[0099] The step of copying the files modified by the patch in the container to the host machine includes:

[0100] Step S51, using Go language to traverse the target software installation directory in the container, calculating the hash value of the file and comparing it with the original file to obtain a list of modified files;

[0101] Step S52, only the files in the modified file list are extracted to the temporary directory of the host machine through the container export function;

[0102] Step S53, run the automation verification module again to verify the exported files on the host machine against the original software, and if the verification is passed, overwrite the original files, otherwise, discard the files.

[0103] The calculation of the hash value of the file refers to the process of generating a unique identifier of the file through a hash algorithm, which can be implemented by using the SHA-256 algorithm, and is used to accurately identify the modified file and avoid resource waste caused by full replication. The container export function refers to an operating interface for transferring files in the container to the host computer, which can be implemented through the container file system export interface of the Docker API, and is used to realize the directional transmission of files in and out of the container. The temporary directory of the host computer refers to the temporary storage space allocated by the operating system, which can be created by using the os.MkdirTemp function of the Go language, and is used to isolate the storage of the patch file to be verified. The re-execution of the automated verification module refers to the secondary verification of the synchronized host environment, which can be implemented by reusing the test script of step S4, and is used to ensure the compatibility of the patch file in the real environment.

[0104] When the patch program in the container is executed, the hash value comparison algorithm is used to quickly locate the changed files, for example, only the files with inconsistent hash values are filtered to generate a modified file list. Then, through the export function of the container management interface, the files in the modified file list are batch-transferred to the temporary storage area of the host computer. Before covering the original files, the automated verification module reloads the target software on the host computer and executes the predefined functional test cases, such as verifying the software startup time, memory occupancy, and core business processes. Only when all test items pass the preset threshold, the patch file in the temporary directory can be moved to the target installation directory to complete the final update.

[0105] The traditional method usually directly copies the entire directory when synchronizing the patch file, which can easily cause redundant file coverage or configuration conflicts. The existing virtualization scheme needs to export the complete virtual machine image, for example, the vmdk file export operation of VMware takes more than 10 minutes. The present scheme realizes incremental synchronization through hash comparison, for example, only 5% of the modified files are transmitted, and the effectiveness of the patch in the real environment is ensured through secondary verification, avoiding the risk of environmental pollution caused by direct coverage.

[0106] The present application further proposes a software patch safe execution system based on container isolation, which comprises a user interface module, a container management module, a network monitoring module, an automated verification module and a file synchronization module, all of which are implemented by Go language.

[0107] The user interface module is an interactive unit for receiving user input information, which can be implemented by using the fmt package and the flag package in Go language to parse command line parameters, or using the fyne framework to build a graphical interface, which is used to collect the target software path and the patch file path, and provide input parameters for subsequent processing.

[0108] The container management module refers to a control unit for creating a temporary container environment. Specifically, it can create a temporary container by invoking DockerSDK or executing the docker run command, and mount the target software directory of the host machine to the container in read-only mode to prevent irreversible modification of the original files by the patch program.

[0109] The network monitoring module refers to a security unit for intercepting and analyzing network communication. Specifically, it can use the net package and gopacket library of Go language to build a transparent proxy, redirect container traffic through iptables rules, and display the source address, target port, and data content of network requests in real time to provide an interactive decision interface for users.

[0110] The automated verification module refers to a testing unit for detecting software functions. Specifically, it can start the target software process through the os / exec package of Go language, match log output with regular expressions, or call Headless Chrome for interface element detection to verify the integrity of core functions after patch application.

[0111] The file synchronization module refers to an operation unit for data migration. Specifically, it can use the file system traversal interface of Go language to compare the hash value differences of files inside and outside the container, and use the container snapshot export function to overwrite the modified files that pass verification to the original directory on the host machine.

[0112] When the user submits the target software path and patch file path through the command line or graphical interface, the container management module starts a temporary container environment, mounts the software installation directory of the host machine in read-only mode, and mounts the patch file as an executable file. The network monitoring module establishes a transparent proxy channel on the host machine side, captures network connection requests initiated by the patch program inside the container in real time, and prompts the user to confirm release or interception through a pop-up dialog box or terminal prompt. The automated verification module runs predefined test scripts inside the container, such as simulating user operation processes after starting the target software to check if the response results of key functions meet expectations. When all network requests are authorized and function verification is passed, the file synchronization module identifies the modified files through hash value comparison, exports them from the container, and overwrites the original files on the host machine. If any step encounters an exception, the container environment will be immediately destroyed to ensure that no modification traces are left.

[0113] The traditional patch deployment scheme directly installs in the host environment, lacks dynamic monitoring mechanism for network behavior, and relies on manual function verification. The system limits patch execution in a temporary environment through container isolation technology, realizes real-time interception of network requests and user interaction through transparent proxy, and verifies software function through automatic test script, which significantly shortens the patch verification period under the premise of ensuring security. Compared with the virtual machine scheme, the starting time of the container environment can be shortened to seconds, and the resource occupation is reduced by about 80%, which is more suitable for scenarios that need to frequently test patches.

[0114] The software patch safe execution system based on container isolation further includes a whitelist management module for storing known safe patch program features, the patch program features including file hash value, destination address and port of network request; when the features of the patch program match the records in the whitelist, the network request is automatically allowed, and the user confirmation step is skipped.

[0115] The whitelist management module refers to a database component for storing trusted patch features, which can be implemented by a key-value pair database or a relational database, and is used for fast matching of the hash value and network behavior features of the current patch. The file hash value refers to the digital fingerprint of the patch program generated by the SHA-256 algorithm, which can be implemented by the Go language crypto / sha256 package, and is used for verifying the integrity of the patch file. The destination address and port of the network request refer to the combination of the target IP and port number in the TCP / IP protocol, which can be implemented by parsing the IP header and TCP header of the network packet, and is used to identify whether the communication target belongs to a trusted server.

[0116] The whitelist management module loads the preset trusted patch feature data in the system initialization stage. When the network monitoring module captures the network request initiated by the patch program, the target address, port and patch file hash value of the request are first extracted and compared with the whitelist database in real time. If all three features match, the network request is directly released and the log is recorded; if some features do not match, the user confirmation process is triggered. This module includes known safe network communication behavior in the automatic processing category by establishing a trusted feature library, reducing the frequency of manual intervention.

[0117] The traditional firewall can only filter network traffic based on static rules and cannot make dynamic decisions based on patch file features. The patch identity authentication and network behavior control are combined through the whitelist mechanism to shorten the execution process time of trusted patches under the premise of ensuring security, for example, the network request of the official patch of the manufacturer that has passed the security audit can be exempted from manual review.

[0118] It should be pointed out that the parts not involved in the present application are the same as or can be realized by using the prior art. The above description is only the preferred embodiment of the present application, but the protection scope of the present application is not limited thereto, any person skilled in the art can make equivalent replacement or change within the technical range disclosed by the present application according to the technical scheme and the inventive concept of the present application, which should be covered in the protection scope of the present application.

Claims

1. A software patch secure execution method based on container isolation, characterized in that, The method comprises the following steps: Step S1, receiving a target software installation path and a patch program file path; Step S2, creating a temporary container environment and mounting a directory: Use the container management interface to call Go language to create a temporary container environment, and mount the target software installation directory to the first path of the container in read-only mode, and mount the patch program in the form of an executable file to the second path of the container; the temporary container environment is configured to prohibit persistent storage, and is automatically destroyed after the container exits; the steps of creating a temporary container environment are as follows: Step S21, use the os / exec package of Go language to call the Docker command line tool or use the Docker SDK of Go language to create a container; Step S22, configure an independent network namespace for the container; Step S23, start a daemon process in the container to receive the execution command sent by the host; Step S3, run the network monitoring module to intercept the request when executing the patch program in the container: When executing the patch program in the container, run the network monitoring module written by Go language on the host, and the network monitoring module intercepts all network requests of the patch program in the container by creating a transparent proxy; When the network monitoring module detects a network request, it pauses the network request and displays a dialog box to the user, prompting the user to select allow or block; the processing function of the network request is: ， wherein, represents a processing request function, represents output as allow, represents output as block; represents a network request; Creating a transparent proxy comprises the following steps: Step S31, listen to raw network packets on the host using the net package and gopacket library in Go language; Step S32, redirect the outbound traffic of the container to the port listened to by the proxy program by configuring iptables rules; Step S33, after receiving the redirected traffic, the proxy program parses and extracts the target address, source address, port and data content; Step S34, display the information on the user interaction interface, and according to the user's selection, the network request is released or intercepted by the proxy program; Step S4, run the target software in the container, execute the function test script defined in advance by the automatic verification module, verify the software function, and judge the core function of the software; Step S5, according to the verification result and the network behavior, decide whether to synchronize the file.

2. The software patch secure execution method based on container isolation according to claim 1, characterized in that, In step S4, the target software is run in the container, and the automatic verification module written in Go language executes the pre-defined function test script to determine whether the core function of the target software is running normally, and the expression of the software function verified by the automatic verification module after patching is as follows: ， wherein, represents a verification result, represents success, represents failure, represents the total number of test items, represents the weight of the th test item, represents the result of the th test item; represents a preset threshold value.

3. The software patch secure execution method based on container isolation according to claim 2, characterized in that, The automatic verification module written in Go language executes the pre-defined function test script, which comprises: Step S41, start the target software and execute the key operation sequence; Step S42, capture the output log of the target software, use the regexp package in Go language for regular matching, and check whether it contains the expected success pattern; Step S43, check the state of the control on the interface of the target software, and obtain the state information through OCR or an automatic test tool.

4. The software patch secure execution method based on container isolation according to claim 1, characterized in that, In step S5, it is decided whether to synchronize files according to the verification result and network behavior. If the function verification is successful and the user does not block any network request, the files modified by the patch in the container are copied to the target software installation directory of the host; otherwise, all changes in the container are discarded.

5. The software patch secure execution method based on container isolation according to claim 3, characterized in that, The copying of the files modified by the patch in the container to the target software installation directory of the host includes: In step S51, the target software installation directory in the container is traversed using Go language, the hash value of the file is calculated and compared with the original file to obtain a list of modified files; In step S52, only the files in the list of modified files are extracted to a temporary directory of the host through the container export function; In step S53, the automatic verification module is run to verify the exported files on the original software of the host, and the original files are overwritten after the verification is passed.

6. A system applied to the software patch secure execution method based on container isolation according to any one of claims 1-5, characterized in that, The system includes: A user interface module that receives a user-specified target software installation path and patch program file path; A container management module implemented in Go language for creating and managing a temporary container environment; A network monitoring module implemented in Go language for intercepting and displaying network requests and waiting for user decisions; An automatic verification module implemented in Go language for executing predefined function test scripts to verify the functions of the patched software; A file synchronization module implemented in Go language for synchronizing the modified files in the container to the host.

7. The system of claim 6, wherein, The system further includes a whitelist management module for storing known safe patch program features, including: File hash value, destination address and port of network request; When the features of the patch program match the records in the whitelist, the network request is automatically allowed, and the user confirmation step is skipped.

Images