A security container-oriented call path analysis method

Abstract

The application discloses a kind of security container-oriented call path analysis methods, including using kernel performance analysis tool perf at the system call entry function in host operating system kernel Insert probe point, using fuzzy test tool syzkaller in gVisor container sandbox inside continuously create, execute a large number of test cases;Start at the same time, using performance analysis tool perf Monitoring container sandbox process triggers the situation of probe point in step one;For the path set collected is filtered, and the path triggered by the system call of the application in the container sandbox is screened out and the like steps, the method of the application combines fuzzy test tool syzkaller and kernel performance analysis tool perf, using dynamic analysis technology automatically triggers the system call of the application kernel sentry in gVisor container, so as to break through the path of sandbox isolation and analyze, solve the analysis difficulty problem caused by gVisor internal complex function call, ensure the accuracy and triggerability of the path obtained.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of container security, in particular to a call path analysis method for secure containers. BACKGROUND

[0002] The gVisor secure container is a new container technology scheme designed for security. It builds a container sandbox and runs an application program in the sandbox. The system calls generated by the application program in the sandbox are redirected to the program sentry also running in the sandbox for processing and return. The sentry is a component of gVisor, which is essentially an application kernel, and it implements a subset of the Linux kernel system call interface (basically meeting the running needs of mainstream application programs). Through the redirection and implementation of the system calls of the application program in the container sandbox, gVisor adds an additional layer of protection between the container application and the host operating system. If the application program in the container wants to attack the host, it must first break through the application kernel of gVisor and then break through to the host from the application kernel layer. The security of gVisor is based on the defense depth it builds, and it can still significantly improve the difficulty of container escape without introducing too much resource overhead.

[0003] The application kernel sentry in the gVisor secure container will send system calls to the host operating system kernel in the process of implementing the system calls of the application program in the container sandbox. This mechanism can be used by attackers to break through the isolation of the container sandbox constructed by gVisor. By constructing a specific system call request, the attacker can trigger the application kernel to send the system call to the host operating system kernel, thereby attacking the host operating system.

[0004] For gVisor secure containers, most of the existing related research works are analysis of its architecture and performance, and do not deeply explore the isolation breakthrough method of the container sandbox it constructs. Although some attacks on gVisor secure containers have been found by related work, limited by the complex system call implementation process and related function call paths in the gVisor application kernel sentry, no work can systematically analyze the way to break through the sandbox isolation. SUMMARY

[0005] The purpose of the present application is to address the deficiencies in the research of gVisor secure containers, and to propose a call path analysis method for secure containers, which is also a sandbox isolation breakthrough path analysis method based on dynamic analysis technology. The present application is implemented by the following technical solutions:

[0006] The present application discloses a call path analysis method for secure containers, comprising the following steps:

[0007] Step one: use the kernel performance analysis tool perf to insert a probe point at the system call entry function in the host operating system kernel;

[0008] Step two: use the fuzz testing tool syzkaller to continuously create and execute a large number of test cases inside the gVisor container sandbox;

[0009] Step three: at the same time as step two, use the performance analysis tool perf to monitor the triggering of the probe point in step one by the container sandbox process;

[0010] Step four: filter the path set collected in step three to select the paths triggered by the system call of the application program in the container sandbox.

[0011] As a further improvement, in step one of the present application, the host operating system kernel is Linux kernel, and the kernel function where the probe point is placed is the Linux system call entry function, which is called when the process in the user space makes a system call, and its name and address in memory are determined by the specific Linux kernel version.

[0012] As a further improvement, in step one of the present application, the probe point in the system call entry function will trigger every time the function is called, so that every system call sent by the container sandbox to the host operating system kernel can be detected.

[0013] As a further improvement, in step two of the present application, by specifying the gVisor secure container as the test object, the fuzz testing tool syzkaller can create a container sandbox and continuously create and execute test cases inside the container sandbox.

[0014] As a further improvement, the fuzz testing tool syzkaller in the present application uses the binary executable file compiled from the gVisor source code to create a container sandbox, and runs the test case generation program in the sandbox. For each test case, the program runs the test case execution program responsible for execution. The executed test case contains a specific sequence of system calls, which are redirected by the container sandbox to the application kernel for processing.

[0015] As a further improvement, in step three of the application, the performance analysis tool perf is used to monitor the triggering of the probe point by the container sandbox process while the container sandbox is being created. When the application kernel in the container sandbox makes a system call, it will fall into the host operating system kernel and call the system call entry function in the kernel, thereby triggering the probe point placed in step one and recording the corresponding timestamp, function call path in the application kernel, and parameter value of the system call entry function when triggered.

[0016] As a further improvement, in step four of the application, based on the specific implementation of the application kernel for the in-container system call, the function name related to the implementation of the in-container system call in the application kernel is matched in the path to be filtered, and the path triggered by the in-container system call is filtered, and the in-container system call name corresponding to the triggered path is obtained.

[0017] The beneficial effects of the application are as follows:

[0018] The method of the application addresses the lack of research and analysis of the isolation breakthrough method of gVisor secure containers, and provides a path analysis method with high accuracy and high availability. The method combines the fuzzy testing tool syzkaller and the kernel performance analysis tool perf, and uses dynamic analysis technology to automatically analyze the system call that can trigger the sentry of the application kernel in the gVisor container, thereby breaking through the sandbox isolation path for analysis, solving the analysis difficulty problem caused by complex function calls in gVisor, and ensuring the accuracy and triggerability of the obtained path. The application provides a reliable analysis technology in the background of the current lack of gVisor container isolation breakthrough method, and the analysis results can be used for attack design of gVisor containers. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 is a call path analysis method for secure containers;

[0020] Figure 2 is a principle diagram of application kernel system call triggering in the analysis process;

[0021] Figure 3 is a principle diagram of application kernel system call triggering monitoring and path recording. DETAILED DESCRIPTION

[0022] The application discloses a call path analysis method for secure containers, and the steps are as follows:

[0023] Step one: use the kernel performance analysis tool perf to insert a probe point at the system call entry function in the host operating system kernel.

[0024] Step two: use the fuzzing tool syzkaller to continuously create and execute a large number of test cases inside the gVisor container sandbox.

[0025] Step three: while step two is started, use the performance analysis tool perf to monitor the triggering of the probe point of the container sandbox process in step one.

[0026] Step four: filter the path set collected in step three to screen out the paths triggered by the system call in the container sandbox application.

[0027] In step one, the host operating system kernel is the Linux kernel, the kernel function where the probe point is placed is the system call entry function of the Linux kernel, which will be called when the process in the user space makes a system call, and the name and address in the memory are determined by the specific Linux kernel version. The probe point in the system call entry function will trigger every time the function is called, so that every system call sent by the container sandbox to the host operating system kernel can be detected.

[0028] In step two, by specifying the gVisor secure container as the test object, the fuzzing tool syzkaller can create a container sandbox and continuously create and execute test cases inside the container sandbox. The fuzzing tool syzkaller uses the binary executable file compiled from the gVisor source code to create a container sandbox, and runs the test case generation program in the sandbox. For each test case, the program will run the test case execution program responsible for execution, and the executed test case contains a specific sequence of system calls, which will be redirected by the container sandbox to the application kernel for processing.

[0029] In step three, while the container sandbox is being created, the performance analysis tool perf is used to monitor the triggering of the probe point by the container sandbox process. When the application kernel in the container sandbox makes a system call, it will fall into the host operating system kernel and call the system call entry function in the kernel, thereby triggering the probe point placed in step one and recording the corresponding timestamp, function call path in the application kernel, and parameter value of the system call entry function when triggered.

[0030] In step four, based on the specific implementation of the application kernel for the container system call, the name of the function related to the implementation of the container system call in the application kernel is matched in the path to be filtered, and the path triggered by the container system call is screened out, and the container system call name corresponding to the triggered path can be obtained.

[0031] The overall architecture of the application will be described below in conjunction with the drawings, Figure 1It is a call path analysis method principle diagram for a secure container, and an overall description is made to the designed application kernel sentry system call trigger path analysis process.

[0032] Step one: use the kernel performance analysis tool perf to insert a probe point at the system call entry function in the host operating system kernel (Linux) (use the perfprobe command). The probe point placed in this step will trigger when the above kernel function is called. After the probe point is triggered, the host operating system kernel will judge whether there is a related perf program monitoring the observation point, if it exists, the perf program corresponding processing operation will be performed.

[0033] Step two: use the fuzz testing tool syzkaller to continuously create and execute a large number of test cases inside the gVisor container sandbox. By specifying the gVisor container as the test object in the configuration document, the fuzz testing tool can create a container sandbox and create and execute test cases inside the container sandbox. Figure 2 It is a principle diagram of the application kernel sentry system call triggered in the analysis process, which vividly describes the process of generating and executing test cases using the fuzz testing tool and triggering the application kernel system call. The syzkaller tool manager will create a gVisor container sandbox according to the configuration document, and run the test case generation program in the sandbox. Each test case generated by the program will be executed by a test case execution program. The test case contains a set of system calls, which will be redirected to the application kernel in the container sandbox and processed subsequently. When processing some specific container system calls, the application kernel will send system calls to the host operating system kernel.

[0034] Step three: at the same time as step two starts, use the performance analysis tool perf to monitor the triggering of the probe point in step one by the container sandbox process (use the perfrecord command). Figure 3is the principle diagram of triggering monitoring and path recording by application kernel sentry system call, which describes the process of triggering monitoring and path recording by using performance analysis tool perf to detect the container instance process. When the application kernel sentry in the container sandbox makes a system call, it will fall into the host Linux kernel and call the system call entry function in the kernel, thereby triggering the pre-placed detection point in step one and recording the call path and other related information. By specifying the process number of the container sandbox process in the host operating system when running the perf tool, as well as the corresponding parameters of the record timestamp, function call path and other functions, the perf tool can monitor the detection point triggered by the container sandbox process, while recording the corresponding timestamp, function call path in the application kernel, and parameter value of the system call entry function.

[0035] Step four: filtering the function call path set collected in step three. In the application kernel sentry, the names of functions responsible for handling the system calls of the application in the container sandbox have specific prefixes. By matching these prefix fields in the path set, the paths that send system calls to the host operating system kernel for the running of the sentry itself can be excluded, thereby successfully filtering out the target paths triggered by the system calls of the application in the container sandbox, and obtaining the container internal system call names corresponding to the triggered paths.

[0036] Those skilled in the art can understand that the above description is only a single example of the invention and is not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical methods described in the foregoing examples or make equivalent replacements for part of the technical features. Any modifications, equivalent replacements, etc. made within the spirit and principles of the invention shall be included in the protection scope of the invention.

Claims

1. A method for call path analysis for a secure container, characterized by, The method comprises the following steps: Step one: for the double-layer architecture of gVisor secure container, the application kernel sentry in the container and the host physical machine Linux kernel, use the kernel performance analysis tool perf to insert a probe point at the system call entry function in the host physical machine Linux kernel, the probe point is used to capture the cross-layer system call sent by the gVisor container to the host physical machine kernel; Step two: use the fuzz testing tool syzkaller to continuously create and execute a large number of test cases inside the gVisor container sandbox, the test cases contain a specific sequence of system calls, which are redirected by the gVisor container to the application kernel sentry inside for processing, to trigger a function call path that may break the gVisor isolation mechanism; Step three: at the same time as step two, use the performance analysis tool perf to monitor the probe point of the host physical machine kernel in real time, realize the coordinated monitoring of "container path triggering-container system call capturing", record the timestamp when the probe point is triggered, the function call path in the gVisor application kernel sentry, and the parameter value of the system call entry function; Step four: based on the implementation logic of the gVisor application kernel sentry for the container system call, filter the path set collected in step three, select the isolation breaking attack path triggered by the application system call in the container sandbox that can make the gVisor container send cross-layer system calls to the host physical machine kernel, and obtain the container system call name corresponding to the attack path.

2. The path analysis method according to claim 1, characterized by, In step one, the host operating system kernel is Linux kernel, the kernel function where the probe point is placed is Linux system call entry function, which will be called when the process in user space makes a system call, its name and address in memory are determined by the specific Linux kernel version.

3. The path analysis method according to claim 1, characterized by, In step one, the probe point in the system call entry function will trigger every time the function is called, so that every system call sent by the container sandbox to the host operating system kernel can be detected.

4. The path analysis method of claim 1, wherein, In step two, by specifying the gVisor secure container as the test object, the fuzz testing tool syzkaller can create a container sandbox and continuously create test cases inside the container sandbox.

5. The path analysis method according to claim 4, characterized by, The fuzz testing tool syzkaller uses the binary executable file compiled from gVisor source code to create a container sandbox and run a test case generation program in the sandbox, for each test case, the program runs a test case execution program responsible for execution, the executed test case contains a specific sequence of system calls, which are redirected by the container sandbox to the application kernel for processing.

6. The path analysis method of claim 1, wherein, In step three, the performance analysis tool perf is used to monitor the triggering of the probe points by the container sandbox process while the container sandbox is being created, and when a system call occurs in the application kernel in the container sandbox, the host operating system kernel is trapped and a system call entry function in the kernel is called, thereby triggering the probe points placed in advance in step one and recording the corresponding time stamp, function call path in the application kernel, and parameter values of the system call entry function when triggered.

7. The path analysis method of claim 1, wherein, In step four, based on the specific implementation of the application kernel for the system call in the container, the names of the functions related to the implementation of the system call in the container in the application kernel are matched in the to-be-filtered path to filter out the path triggered by the system call in the container and obtain the name of the system call in the container corresponding to the path.

Images