CN111651752A - Method for acquiring system call white list required by container - Google Patents
Method for acquiring system call white list required by container Download PDFInfo
- Publication number
- CN111651752A CN111651752A CN202010305553.3A CN202010305553A CN111651752A CN 111651752 A CN111651752 A CN 111651752A CN 202010305553 A CN202010305553 A CN 202010305553A CN 111651752 A CN111651752 A CN 111651752A
- Authority
- CN
- China
- Prior art keywords
- system call
- container
- function
- docker
- instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
- G06F9/4451—User profiles; Roaming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a method for acquiring a system call white list required by a container, which comprises the following steps: 1) acquiring a system call set A which needs to be added into a system call white list when a container is started and an ELF executable file set B which is called when the container runs, and adding the set A into the system call white list; 2) based on the ELF executable file set B obtained in the step 1), performing static analysis on the container to obtain a system call set S which needs to be called in the application running process in the container, and adding the system call set S into a system call white list. Compared with the default configuration of Docker, the system call white list is obtained through dynamic analysis and static analysis, the system call is reduced by 69.27% to 85.89%, and the safety and the operation efficiency are improved.
Description
Technical Field
The invention belongs to the field of container safety, and relates to a method for acquiring a system call white list required by a container, which can be used for analyzing the system call white list required by the container through static analysis and dynamic analysis.
Background
Container technology has been used to run multiple independent operating system releases on a host or to deploy large scale microservice-based applications. Compared with the traditional virtual machine based on the virtual machine, the container has the advantages of higher starting speed, lower resource consumption and higher I/O throughput. Cloud computing vendors use container-based technologies to build platform as a service (PaaS) or to provide customized container services directly to users. With the wide application of cloud computing technology, container-based virtualization technology has been greatly developed in recent years. Numerous container technologies have been proposed by academia and industry, such as Docker, rkt, LXD, etc. Of these container technologies, Docker is the most popular container technology and has found widespread use in the industry. In most cases, a container shares the same kernel with the host and other containers on the same host, and applications in the container can make system calls to the host kernel as normal processes on the host. Seccomp is a security mechanism for the Linux kernel through which the present invention can prohibit programs from performing certain system calls. Docker supports the seccomp mechanism starting from version 1.10, with about 44 system calls disabled out of over 300 system calls by default. However, there are still many system calls that can be executed without running for a particular container, and abusing a system call by an infected container may trigger a security breach of the host kernel. Unfortunately, Docker does not provide a way to obtain the necessary system calls for a particular container. The present invention proposes a method that combines dynamic analysis and static analysis to obtain the necessary system calls for a particular container.
Container-based virtualization and Docker
Container-based virtualization is a lightweight virtualization approach that uses a host kernel to run multiple virtual environments. These virtual environments are often referred to as containers. Unlike virtual machine hypervisor-based virtualization, container-based virtualization virtualizes at the operating system level, thereby eliminating the need to run other operating systems on the host. From the perspective of the host, the container behaves like a regular process running on it. Docker is the most popular open source container solution.
The container mirror is a read-only template that contains the description of creating the Docker container. The Docker image consists of a series of layers. To build its own image, the present invention creates a Dockerfile using a simple syntax to define the steps needed to create the image and run it. Each instruction in the Dockerfile creates a layer in the image. Just as the present invention requires running applications on an operating system, the present invention often uses an OS image as the base image.
Static linking and dynamic linking
The linker is system software, and plays a crucial role in software development because it can be compiled separately. Rather than organizing a large application as a unitary source file, it can be broken down into smaller, more manageable blocks that can be modified and compiled separately. When the invention changes a module, the invention only needs to recompile it and re-link the application, and does not need to recompile other source files.
During static linking, the linker will copy all library routines used in the program into the executable image. Of course, this requires more disk and memory space than dynamic linking. But static links are faster and more portable because it does not require the library to be present on the system on which it is running.
In dynamic linking, on the other hand, the shareable library name is placed in the executable image, while the actual linking occurs when both the executable file and the library are placed in memory at runtime. When writing an application in a compiled language, dynamic linking or static linking techniques will be used. Common compiled languages include C, C + +, Golang, and the like.
Linux ELF binary file
Executable and Linkable Format (ELF) is a standard file format for executable files, object code and shared libraries. The libraries and executables on a Unix-like system are ELFs. The ELF header describes the organization of the entire file at the beginning of the file. This section provides information about the target file, such as instructions, data, symbol tables, relocation information, etc. The program header table is an optional part of the ELF file that indicates how the process image is created.
If a library or executable file is generated by dynamic linking, it will contain a table named. The table contains all references to external functions, and the referenced external functions are located in other shared libraries. In Linux, these shared libraries are typically.so files.
System call instruction
For a program running on Linux to initiate a system call, there are three different instructions:
syscall is the default method to enter kernel mode on the x86-64 architecture. This instruction is not available in the 32-bit operating mode of the Intel processor.
syserter is the most commonly used instruction to invoke a system call in 32-bit mode of operation. It is somewhat difficult to use, similar to syscall.
int 0x80 is a traditional method of invoking system calls and is rarely used on current platforms.
The user program saves the system call ID to be called in the eax or rax register and executes one of the three instructions to issue a system call. For a 64-bit processor, eax and rax point to the same register, but rax represents the 64 bits of the entire register, and eax represents the lower 32 bits of the register.
Disclosure of Invention
The invention aims to provide a method for acquiring a system call white list required by a container. The Docker container by default prohibits 44 system calls, allowing a system call to run much larger than the container requires for a particular container. But there has not been a good solution to how to get as accurate as possible the system calls required by a particular container. The invention obtains the system call needed by the specific container during starting and running through a method of combining static analysis and dynamic analysis.
The technical scheme of the invention is as follows:
a method for obtaining a system call white list required by a container comprises the following steps:
1) acquiring a system call set A which needs to be added into a system call white list when a container is started and an ELF executable file set B which is called when the container runs, and adding the set A into the system call white list;
2) based on the ELF executable file set B obtained in the step 1), performing static analysis on the container to obtain a system call set S which needs to be called in the application running process in the container, and adding the system call set S into a system call white list.
Further, the method for acquiring the system call set a to be added to the system call white list when the container is started comprises: when the docker daemon process receives a request for starting the container, the docker daemon process sends the request to the container, and then the container executes initialization and derives a docker-shim process; the docker-shim process initializes the container environment, including validating the seccomp configuration file; and then respectively adding a system call set A executed by the docker-shim process and a system call set C executed by the application program specified by the user into a system call white list.
Further, a sleep operation pause program is set in the docker source code; after the seccomp configuration file takes effect, the docker daemon executes the sleep operation to pause the docker-shim process, and then transmits the pid of the docker-shim process to a tracking module running on a host where the container is located; after receiving the pid of the docker-shim process, the tracking module starts a strand instruction to track the system call, then continues to execute the docker-shim process, and obtains a system call set A executed by the docker-shim process.
Before the docker-shim process starts the application program specified by the user, a monitoring module is started to acquire an ELF executable file set B called when the application program specified by the user runs.
Further, the monitoring module is implemented based on an inotify API provided by linux.
Further, in step 2), the container is statically analyzed to obtain a system call set S that needs to be called in the application running process in the container, including obtaining a system call set S' of the statically linked application program in the container and a system call set S ″ of the dynamically linked application program in the container.
Further, the method for obtaining the system call set S ″ of the dynamically linked application in the container includes:
21) setting and maintaining two data structures, wherein the first data structure is used for storing a set S of system call IDs, and the second data structure is used for storing a function to be processed and a queue Q of tuples of positions of a library where the function is located;
22) analyzing the ELF executable files in the set B by using a method for analyzing the statically linked application program, and adding a system call ID obtained by analysis to the set S';
23) obtaining an external function f depended by the dynamically linked application program in the container and obtaining the position l of a library of the external function f in a Got.plt table for storing a function reference address; adding the tuple (f, l) to the queue Q;
24) if the queue Q is empty, acquiring a system call list of the application program from the system call ID in the set S'; otherwise, dequeue a tuple (f, l) from queue Q;
25) disassembling the library pointed by the position l in the current dequeue tuple (f, l), and finding an assembly code corresponding to the function f; then, analyzing the system call of the assembly code of the function f by using a method for analyzing the static link application program, and adding a system call ID obtained by analysis to the set S'; if function f also calls function f1, and function f, function f1 are in current pool l, then add tuple (f1, l) to queue Q; if the function f1 is located in the external library, acquiring the position l1 of the library where the function f1 is located, and then adding the tuple (f1, l1) to the queue Q; and then returns to step 24).
Further, the method for obtaining the system call set S' of the statically linked application program in the container includes: the statically linked application program in the disassembling container traverses all assembly instructions of the application program from beginning to end; a) if a syscall instruction which does not belong to the syscall function is encountered, analyzing instructions before the syscall instruction until a jump instruction, an instruction for calling the function or a first instruction at the beginning of the function is encountered; if an instruction I before the syscall instruction belongs to Type I or Type II, acquiring a system call corresponding to the instruction I and adding the system call to a set S'; type I refers to directly assigning the system call ID to the eax or rax register, type II refers to indirectly assigning the system call ID to the eax or rax register using only one register; b) if a callq < syscall > instruction is encountered, the system call corresponding to the callq < syscall > instruction is retrieved from the edi register and added to set S'.
A service platform based on a container technology is characterized in that a system call white list required by a container is obtained by the method.
The invention discloses a method for obtaining a system call white list required by a container based on dynamic analysis and static analysis, which mainly comprises the following two stages of dynamic analysis and static analysis:
dynamic analysis:
the dynamic analysis mainly comprises two targets: system calls that need to be added to the whitelist are obtained at container start-up, and the necessary ELF executables are obtained at container run-time.
1) Acquiring a system call: in the Docker architecture, a Docker daemon is responsible for creating and launching containers. When the docker daemon receives a user request to start a container, it will send the user request into the container through the gRPC. The container performs different operations according to the user's request, such as installing a file system, initializing a container network, etc. If a user requests to start a container, the container will first perform a series of initialization tasks and then spawn a docker-shim process. docker-shim will also perform some work to initialize the container environment, including validating the seccomp profile (system call whitelist). After the seccomp configuration file takes effect, the docker-shim and the child processes thereof can only execute system calls in the white list, but the docker daemon is not affected. Therefore, the system call that needs to be added to the whitelist is a system call executed by the docker-shim and the user-specified application after the seccomp profile is validated. In the dynamic analysis stage, the system call executed by docker-shim after the seccomp configuration file takes effect is obtained.
2) Acquiring the necessary ELF executable file: in the process of building a container image, the present invention sometimes requires some ancillary tools to build the image. For example, the invention might install a wget application and use it to download some tools or files. In fact, the wget application is used in the process of building the MySQL image. However, the containers do not use these tools when running the user's application, and may not be deleted after they are used during the construction of the image. Thus, the present invention requires the use of dynamic analysis to find out which executables a container uses at runtime.
Static analysis
And obtaining which system calls are needed in the running process of the application in the container in the static analysis stage.
1) Analyzing the system call: on a Linux platform, when the present invention uses a non-assembly high-level language to write a program, the present invention analyzes a system call provided through a Linux kernel in three ways: first, the program calls a system call through the wrapper function in libc library. Each specific system call corresponds to at least one wrapper function. This is the most common method. The invention disassembles the wrapper function in libc and finds that the assembly code of the wrapper function in libc has the following two types:
type I: direct assignment of System Call ID to eax or rax register
mov $0x8,％r10d
mov $0xe,％eax
syscall
Type II: the system call ID is indirectly assigned to the eax or rax register through other registers, and only one register is used in the process
Secondly, the system call is called by the syscall function of the Linux kernel. Using the syscall function is useful when calling a wrapper function that does not have the system call in the libc library. The assembly code that invokes a system call in this manner is as follows:
type III: the system call ID is first stored in the edi register and then the "syscall" function is called. In the < syscall > function, the system call ID in the edi register is assigned to the rax register.
2) System call of statically linked application and system call of dynamically linked application: firstly, a specific path of a binary file which needs to be executed when an application runs is obtained through dynamic analysis, and then the corresponding binary file is disassembled to obtain an assembly instruction. And then, obtaining the system call ID of the system call required in the container operation process by matching the three modes, thereby obtaining the corresponding system call.
The invention has the beneficial effects that:
based on the static analysis and the dynamic analysis, the system call required by the specific container in the whole life cycle can be obtained.
The invention selects 6 common containers from Docker Hub and then analyzes their system calls using dynamic analysis and dynamic analysis methods. The results obtained by both methods are then merged after the duplicate system calls are deleted. Finally, the percentage reduction compared to 333 system calls defaulted by Docker was calculated. The results are shown in Table 1. It can be seen by the present invention that the results obtained by dynamic analysis and static analysis are in part consistent. These coincident system calls include mmap, read, futex, etc., which are typically used during container startup and runtime. In addition, the dynamic analysis phase records the system call executed when the application program in the container is started, and the part of the system call can also be obtained through static analysis. Therefore, a significant portion of the results obtained by dynamic analysis and static analysis overlap. For these 6 containers, the present invention reduces system calls by 69.27% to 85.89% compared to the default configuration of Docker.
Table 1 shows the number of system calls made at different stages
| Container with a lid | Dynamic analysis | Static analysis | After merging | Percentage of reduction |
| MySQL | 72 | 79 | 101 | 69.67％ |
| Postgres | 72 | 85 | 102 | 69.27％ |
| MongoDB | 73 | 73 | 96 | 71.17％ |
| Redis | 53 | 46 | 67 | 79.88％ |
| memcached | 26 | 36 | 47 | 85.89％ |
| etcd | 39 | 48 | 60 | 81.98％ |
Drawings
FIG. 1 is a flow chart of a method of the present invention;
FIG. 2 is a flowchart of a method for acquiring the set S'.
Detailed Description
The present invention will be described in further detail with reference to the accompanying drawings.
The method flow of the invention is as shown in fig. 1, firstly, when a container is started, a system call set A which needs to be added into a system call white list and an ELF executable file set B which is called when the container runs are obtained, and the set A is added into the system call white list; and then, based on the obtained ELF executable file set B, performing static analysis on the container to obtain a system call set S which needs to be called in the application running process in the container and adding the system call set S into a system call white list.
1. The system calls for a particular container are dynamically analyzed.
In order to track which system calls are executed by the docker-shim and the child processes thereof after the seccomp configuration file takes effect, the docker source code is modified. After executing the code thereto, the present invention adds a sleep operation suspend routine to the execution. After the seccomp configuration file takes effect, the invention immediately suspends the docker-shim process. Since a container is a set of processes that share the same set of kernel resources, the processes within the container are, from the perspective of the host OS, normal processes with different properties (e.g., pid, uid, and gid). Therefore, the invention passes the pid of the docker-shim process to the trace module running on the host OS where the container is located. And after receiving the pid of the docker-shim process, the tracking module starts the strand to track the system call. Finally, after the strand is started, the invention will continue to execute the docker-shim process.
Before docker-shim launches a user-specified application, the invention launches a monitoring module to obtain which ELF executables to use while the application is running. Each layer of the Docker image corresponds to a folder on the host operating system. Therefore, the invention realizes the monitoring module based on the inotify API provided by Linux. inotify can monitor the directory for events such as reads, writes, accesses, etc. that occur to a file. The monitoring module monitors the docker image for each layer's corresponding folders and records which ELF executables are accessed. After the dynamic analysis phase is over, the results are passed to static analysis.
2. The system calls for a particular container are statically analyzed.
(1) System call of statically linked application: from the above analysis, the present invention can easily obtain the system call of the application generated by the static link. The invention first disassembles the application and then traverses all assembly instructions from beginning to end. If a syscall instruction is encountered but it does not belong to the syscall function, the invention analyzes the instructions preceding the syscall instruction from beginning to end to detect whether they belong to Type I or Type II. If they belong to either Type I or Type II, the invention can easily obtain the corresponding system call ID, and then can obtain the system call corresponding to the system call ID and add to the set S'. The analysis process ends until a jump instruction is encountered, the instruction of the function is called or the first instruction at the beginning of the function. If a callq < syscall > instruction is encountered, it indicates that it belongs to III. The invention can then obtain the system call ID from the edi register and add it to the set S'. The invention obtains the system call set S required to be called in the application running process in the container by carrying out static analysis on the container, and comprises a system call set S 'of the application program statically linked in the container and a system call set S' of the application program dynamically linked in the container.
(2) System call of dynamically linked application: for a dynamically linked application, the present invention analyzes not only the system calls of the ELF executable file of the application, but also the system calls of the external functions on which the application depends. The dependent external functions are typically located in a dynamically linked library, and the dynamically linked library itself may be generated by dynamic linking or static linking. Therefore, the present invention proposes the following method to analyze the system call of the dynamically linked application. As shown in fig. 2, the method is mainly divided into the following 6 steps:
step 1. maintain two data structures: the set S "of system call IDs is reserved and the queue Q holding the tuple of the function to be processed and the location of the library in which the function is located.
And 2, analyzing the ELF executable file of the application program (namely the ELF executable file in the system call white list obtained by dynamic analysis) by using the method for analyzing the statically linked application program, and adding the system call ID obtained by analysis to S ".
And 3, acquiring the external function f depended by the application program in the go. The location/of the library where the external function is located is obtained using the ldd tool. The tuple (f, l) is added to the queue Q.
And 4, if the queue Q is empty, turning to the step 6. Otherwise, one tuple (f, l) is dequeued from queue Q.
And 5, disassembling the library pointed by the assembly position l, and finding an assembly code corresponding to the function f. The method of analyzing the statically linked application is used to analyze the system call of the assembly code of the function f and add the system call ID obtained by the analysis to the set S ". If function f also calls other function f1, and function f1 is in the current pool, then the tuple (f1, l) is added to queue Q. If the function f1 is located in an external bank, then the location of the bank is retrieved using ldd, i 1, and then the tuple (f1, i 1) is added to queue Q. And returning to the step 4.
And 6, acquiring a system call list of the application program from the system call ID in the set S'.
Examples
A user downloads a container from Docker Hub but is not aware of whether the application running in the container is trusted and secure, and the user wants to restrict as much as possible the invocable system calls of the container while not affecting the normal function of the container. Then the user can use the invention to obtain the system calls required by the container, and then add the system calls into the seccomp configuration file white list of the container, and use the configuration file as the system call white list of the container when the container is really started.
While the foregoing disclosure shows illustrative embodiments of the invention, it should be noted that various changes and modifications could be made herein without departing from the scope of the invention as defined by the appended claims. Therefore, the scope of the present invention should be determined by the contents of the appended claims.
Claims (9)
1. A method for obtaining a system call white list required by a container comprises the following steps:
1) acquiring a system call set A which needs to be added into a system call white list when a container is started and an ELF executable file set B which is called when the container runs, and adding the set A into the system call white list;
2) based on the ELF executable file set B obtained in the step 1), performing static analysis on the container to obtain a system call set S which needs to be called in the application running process in the container, and adding the system call set S into a system call white list.
2. The method of claim 1, wherein the method for obtaining the system call set a to be added to the system call white list when the container is started comprises: when the docker daemon process receives a request for starting the container, the docker daemon process sends the request to the container, and then the container executes initialization and derives a docker-shim process; the docker-shim process initializes the container environment, including validating the seccomp configuration file; and then respectively adding a system call set A executed by the docker-shim process and a system call set C executed by the application program specified by the user into a system call white list.
3. The method of claim 2, wherein a sleep operation pause program is set in the docker source code; after the seccomp configuration file takes effect, the docker daemon executes the sleep operation to pause the docker-shim process, and then transmits the pid of the docker-shim process to a tracking module running on a host where the container is located; after receiving the pid of the docker-shim process, the tracking module starts a strand instruction to track the system call, then continues to execute the docker-shim process, and obtains a system call set A executed by the docker-shim process.
4. The method of claim 2, wherein a monitoring module is launched to obtain the set B of ELF executables called by the user-specified application run-time before the docker-shim process launches the user-specified application.
5. The method of claim 4, wherein the monitoring module is implemented based on an inotify API provided by linux.
6. The method according to claim 1, wherein in step 2), the container is statically analyzed to obtain a system call set S required to be called during the running process of the application in the container, and the method comprises obtaining a system call set S' of the statically linked application in the container and a system call set S ″ of the dynamically linked application in the container.
7. The method of claim 6, wherein the method of obtaining the set of system calls S "for the dynamically linked application in the container is:
21) setting and maintaining two data structures, wherein the first data structure is used for storing a set S of system call IDs, and the second data structure is used for storing a function to be processed and a queue Q of tuples of positions of a library where the function is located;
22) analyzing the ELF executable files in the set B by using a method for analyzing the statically linked application program, and adding a system call ID obtained by analysis to the set S';
23) obtaining an external function f depended by the dynamically linked application program in the container and obtaining the position l of a library of the external function f in a Got.plt table for storing a function reference address; adding the tuple (f, l) to the queue Q;
24) if the queue Q is empty, acquiring a system call list of the application program from the system call ID in the set S'; otherwise, dequeue a tuple (f, l) from queue Q;
25) disassembling the library pointed by the position l in the current dequeue tuple (f, l), and finding an assembly code corresponding to the function f; then, analyzing the system call of the assembly code of the function f by using a method for analyzing the static link application program, and adding a system call ID obtained by analysis to the set S'; if function f also calls function f1, and function f, function f1 are in current pool l, then add tuple (f1, l) to queue Q; if the function f1 is located in an external library, acquiring the position l1 of the library where the function f1 is located, and then adding the tuple (f1, l1) to the queue Q; and then returns to step 24).
8. The method of claim 6, wherein the method of obtaining the set of system calls S' for statically linked applications in the container is: the statically linked application program in the disassembling container traverses all assembly instructions of the application program from beginning to end; a) if a syscall instruction which does not belong to the syscall function is encountered, analyzing instructions before the syscall instruction until a jump instruction, an instruction for calling the function or a first instruction at the beginning of the function is encountered; if an instruction I before the syscall instruction belongs to Type I or Type II, acquiring a system call corresponding to the instruction I and adding the system call to a set S'; type I refers to directly assigning the system call ID to the eax or rax register, type II refers to indirectly assigning the system call ID to the eax or rax register using only one register; b) if a callq < syscall > instruction is encountered, the system call corresponding to the callq < syscall > instruction is retrieved from the edi register and added to set S'.
9. A service platform based on container technology, characterized in that the method according to any claim 1 to 8 is used to obtain the system call white list required by the container.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010305553.3A CN111651752B (en) | 2020-04-17 | 2020-04-17 | Method for acquiring system call white list required by container |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010305553.3A CN111651752B (en) | 2020-04-17 | 2020-04-17 | Method for acquiring system call white list required by container |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111651752A true CN111651752A (en) | 2020-09-11 |
| CN111651752B CN111651752B (en) | 2022-10-14 |
Family
ID=72352147
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010305553.3A Active CN111651752B (en) | 2020-04-17 | 2020-04-17 | Method for acquiring system call white list required by container |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111651752B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114238153A (en) * | 2022-02-21 | 2022-03-25 | 麒麟软件有限公司 | Binary file detection method in Linux system |
| KR20220163608A (en) * | 2021-06-03 | 2022-12-12 | 한국과학기술원 | Method and system for runtime security profile update of containers |
| CN115567634A (en) * | 2022-09-05 | 2023-01-03 | 青岛海信移动通信技术股份有限公司 | Network management method, device, equipment and storage medium |
| WO2023282439A1 (en) * | 2021-07-08 | 2023-01-12 | 숭실대학교 산학협력단 | Analysis method for container system call configuration error, and recording medium and apparatus for performing same |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106576105A (en) * | 2014-09-24 | 2017-04-19 | 迈克菲股份有限公司 | Non-invasive whitelisting |
| CN106874747A (en) * | 2017-02-21 | 2017-06-20 | 郑州云海信息技术有限公司 | A kind of Unix white list control methods based on hook technologies |
| US20180129803A1 (en) * | 2015-10-01 | 2018-05-10 | Twistlock, Ltd. | Filesystem action profiling of containers and security enforcement |
| CN109145532A (en) * | 2018-08-20 | 2019-01-04 | 北京广成同泰科技有限公司 | A kind of program white list management method and system for supporting on-line software updating |
-
2020
- 2020-04-17 CN CN202010305553.3A patent/CN111651752B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106576105A (en) * | 2014-09-24 | 2017-04-19 | 迈克菲股份有限公司 | Non-invasive whitelisting |
| US20180129803A1 (en) * | 2015-10-01 | 2018-05-10 | Twistlock, Ltd. | Filesystem action profiling of containers and security enforcement |
| CN106874747A (en) * | 2017-02-21 | 2017-06-20 | 郑州云海信息技术有限公司 | A kind of Unix white list control methods based on hook technologies |
| CN109145532A (en) * | 2018-08-20 | 2019-01-04 | 北京广成同泰科技有限公司 | A kind of program white list management method and system for supporting on-line software updating |
Non-Patent Citations (3)
| Title |
|---|
| KIKAJACK: "Docker 生产环境之安全性 - 适用于 Docker 的 Seccomp 安全配置文件", 《HTTPS://BLOG.CSDN.NET/KIKAJACK/ARTICLE/DETAILS/79596843》 * |
| SUYEOL LEE 等: "Tclp: Enforcing least privileges to prevent containers from kernel vulnerabilities", 《CCS "19: PROCEEDINGS OF THE 2019 ACM SIGSAC CONFERENCE ON COMPUTER AND COMMUNICATIONS SECURITY》 * |
| 冯圣琴: "【开源容器】Docker-slim介绍", 《HTTPS://WWW.SOHU.COM/A/195592323_468741》 * |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20220163608A (en) * | 2021-06-03 | 2022-12-12 | 한국과학기술원 | Method and system for runtime security profile update of containers |
| KR102571477B1 (en) | 2021-06-03 | 2023-08-29 | 한국과학기술원 | Method and system for runtime security profile update of containers |
| WO2023282439A1 (en) * | 2021-07-08 | 2023-01-12 | 숭실대학교 산학협력단 | Analysis method for container system call configuration error, and recording medium and apparatus for performing same |
| KR20230009012A (en) * | 2021-07-08 | 2023-01-17 | 숭실대학교산학협력단 | Method for analyzing against container system call misconfiguration, recording medium and device for performing the method |
| KR102493782B1 (en) * | 2021-07-08 | 2023-01-31 | 숭실대학교 산학협력단 | Method for analyzing against container system call misconfiguration, recording medium and device for performing the method |
| CN114238153A (en) * | 2022-02-21 | 2022-03-25 | 麒麟软件有限公司 | Binary file detection method in Linux system |
| CN114238153B (en) * | 2022-02-21 | 2022-07-08 | 麒麟软件有限公司 | Binary file detection method in Linux system |
| CN115567634A (en) * | 2022-09-05 | 2023-01-03 | 青岛海信移动通信技术股份有限公司 | Network management method, device, equipment and storage medium |
| CN115567634B (en) * | 2022-09-05 | 2024-03-29 | 青岛海信移动通信技术有限公司 | Network management method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111651752B (en) | 2022-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Olivier et al. | A binary-compatible unikernel | |
| CN111651752B (en) | Method for acquiring system call white list required by container | |
| US10635415B2 (en) | Run-time interception of software methods | |
| Hookway et al. | Digital FX! 32: Combining emulation and binary translation | |
| US8489925B1 (en) | System and method for processing of system errors | |
| US8364461B2 (en) | Reusing invalidated traces in a system emulator | |
| US6704927B1 (en) | Static binding of dynamically-dispatched calls in the presence of dynamic linking and loading | |
| US9201635B2 (en) | Just-in-time dynamic translation for translation, compilation, and execution of non-native instructions | |
| Zhang et al. | {KylinX}: A dynamic library operating system for simplified and efficient cloud virtualization | |
| US9213563B2 (en) | Implementing a jump instruction in a dynamic translator that uses instruction code translation and just-in-time compilation | |
| US9524178B2 (en) | Defining an instruction path to be compiled by a just-in-time (JIT) compiler | |
| US9529610B2 (en) | Updating compiled native instruction paths | |
| US20040083467A1 (en) | System and method for executing intermediate code | |
| US10628177B1 (en) | Unikernel provisioning | |
| US9183018B2 (en) | Dynamic on/off just-in-time compilation in a dynamic translator using instruction code translation | |
| Wang et al. | Rsds: Getting system call whitelist for container through dynamic and static analysis | |
| Olivier et al. | A syscall-level binary-compatible unikernel | |
| Kleissner | Stoned bootkit | |
| JP5129904B2 (en) | Method for increasing function execution performance during execution, computer system, and computer-readable medium storing a computer program for increasing function execution performance during execution | |
| Choi et al. | Hybrid emulation for bypassing anti-reversing techniques and analyzing malware | |
| US20220147376A1 (en) | Selective substitution of legacy load module programs with classes for execution in a java virtual machine | |
| Hookway | DIGITAL FX! 32 running 32-Bit x86 applications on Alpha NT | |
| Wen et al. | WasmAndroid: a cross-platform runtime for native programming languages on Android (WIP paper) | |
| Bertin et al. | Compilation and virtualization in the HiPEAC vision | |
| US11989569B2 (en) | Unikernel provisioning |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |