CN111651752B - 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
- CN111651752B CN111651752B CN202010305553.3A CN202010305553A CN111651752B CN 111651752 B CN111651752 B CN 111651752B CN 202010305553 A CN202010305553 A CN 202010305553A CN 111651752 B CN111651752 B CN 111651752B
- Authority
- CN
- China
- Prior art keywords
- system call
- container
- docker
- function
- 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.)
- Active
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)
- Debugging And Monitoring (AREA)
- Stored Programmes (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 required to be called in the application running process in the container, and adding the system call set S to 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, and by default, out of 300 or more system calls, approximately 44 system calls are disabled. 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 Dockerfile creates a layer in the image. Just as the present invention requires running applications on the 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 into 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, without recompiling 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 an application is written 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. Libraries and executables on Unix-like systems 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.
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 mode of operation of the Intel processor.
syserter is the most commonly used instruction to invoke a system call in 32-bit mode of operation. It is similar to syscall and is somewhat difficult to use.
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, while 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, and for a particular container, allows a system call to run much larger than the container needs. But there has been no good solution to how to get as accurate as possible the system calls needed for a particular container. The invention obtains the system call required by the specific container during starting and running by 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 includes: when a docker daemon process receives a request for starting a 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 process 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 Two data structures are set and maintained, 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 Analyze ELF executables in set B using methods that analyze statically linked applications, add the system call ID obtained from the analysis to set S ";
23 Go. Add tuple (f, l) to queue Q;
24 If queue Q is empty, then obtain the system call list of the application from the system call ID in set S'; otherwise, dequeue a tuple (f, l) from queue Q;
25 Disassembling the library pointed to 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 into a set S'; if the function f also calls the function f1, and the function f1 are located in the current library l, adding the tuple (f 1, l) into the 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 (f 1, l 1) to a 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 means that the system call ID is directly allocated to the eax or rax register, and type II means that the system call ID is indirectly allocated to the eax or rax register by 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 seccomp configuration files (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 auxiliary tools to build the image. For example, the invention might install a wget application and use it to download some tools or files. In practice, 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 particular 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 IDs to eax or rax registers
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 calls the system call in this way 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 present invention selects 6 commonly used 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 the dynamic analysis and the static analysis are partially 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 considerable portion of the results obtained by the dynamic analysis and the static analysis overlap. For these 6 containers, the present invention reduced 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 | 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 disclosure is described in further detail below with reference to the attached drawing figures.
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 pauses 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, ordinary processes that have 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 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 functions f1, and function f1 is located in the current pool, then the tuple (f 1, l) is added to queue Q. If the function f1 is located in an external bank, then location l1 of the bank is obtained using ldd, and then the tuple (f 1, l 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 present invention to obtain the system calls required by the container, and then add these 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. Accordingly, the scope of the invention should be determined from the content of the appended claims.
Claims (7)
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 and an ELF executable file set B which is called when the container runs when the container is started, 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;
the system call set S comprises a system call set S 'for obtaining the statically linked application programs in the container and a system call set S' for the dynamically linked application programs in the container; the method for obtaining the system call set S' of the application program statically linked in the container comprises the following steps: disassembling the statically linked application program in the container, and traversing 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 the type I or the 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 allocating a system call ID to an eax or rax register, and type II refers to indirectly allocating the system call ID to the eax or rax register by 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'.
2. The method of claim 1, wherein the method for obtaining the set of system calls a to be added to the system call white list when the container is started is: when a docker daemon process receives a request for starting a 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 process 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 of claim 1, wherein the method of obtaining the set of system calls S "for the dynamically linked application in the container is:
21 Two data structures are set and maintained, 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 Analyze ELF executables in the set B using a method of analyzing statically linked applications, add the system call ID obtained from the analysis to the set S ";
23 Go. Add tuple (f, l) to queue Q;
24 If queue Q is empty, then obtain the system call list of the application from the system call ID in set S'; otherwise, dequeue a tuple (f, l) from queue Q;
25 Disassembling the library pointed to 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 the function f also calls the function f1, and the function f1 are located in the current library l, adding the tuple (f 1, l) into the 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 tuples (f 1, l 1) to a queue Q; and then returns to step 24).
7. A system based on container technology, characterized in that the method according to any of claims 1-6 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 CN111651752A (en) | 2020-09-11 |
| CN111651752B true 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) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102571477B1 (en) * | 2021-06-03 | 2023-08-29 | 한국과학기술원 | Method and system for runtime security profile update of containers |
| KR102493782B1 (en) * | 2021-07-08 | 2023-01-31 | 숭실대학교 산학협력단 | Method for analyzing against container system call misconfiguration, recording medium and device for performing the method |
| CN114238153B (en) * | 2022-02-21 | 2022-07-08 | 麒麟软件有限公司 | Binary file detection method in Linux system |
| CN115567634B (en) * | 2022-09-05 | 2024-03-29 | 青岛海信移动通信技术有限公司 | Network management method, device, equipment and storage medium |
Citations (3)
| 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 |
| CN109145532A (en) * | 2018-08-20 | 2019-01-04 | 北京广成同泰科技有限公司 | A kind of program white list management method and system for supporting on-line software updating |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10664590B2 (en) * | 2015-10-01 | 2020-05-26 | Twistlock, Ltd. | Filesystem action profiling of containers and security enforcement |
-
2020
- 2020-04-17 CN CN202010305553.3A patent/CN111651752B/en active Active
Patent Citations (3)
| 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 |
| 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 |
|---|
| 【开源容器】Docker-slim介绍;冯圣琴;《https://www.sohu.com/a/195592323_468741》;20170930;第1-3页 * |
| Docker 生产环境之安全性 - 适用于 Docker 的 Seccomp 安全配置文件;kikajack;《https://blog.csdn.net/kikajack/article/details/79596843》;20180317;第1-3页 * |
| Tclp: Enforcing least privileges to prevent containers from kernel vulnerabilities;Suyeol Lee 等;《CCS "19: Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security》;20191130;第2665-2667页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111651752A (en) | 2020-09-11 |
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 | |
| Gadepalli et al. | Sledge: A serverless-first, light-weight wasm runtime for the edge | |
| US10635415B2 (en) | Run-time interception of software methods | |
| US10289435B2 (en) | Instruction set emulation for guest operating systems | |
| US8621279B1 (en) | System and method for generating emulation-based scenarios for Error Handling | |
| US8364461B2 (en) | Reusing invalidated traces in a system emulator | |
| US9201635B2 (en) | Just-in-time dynamic translation for translation, compilation, and execution of non-native instructions | |
| US6704927B1 (en) | Static binding of dynamically-dispatched calls in the presence of dynamic linking and loading | |
| 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 | |
| US11061695B2 (en) | Unikernel provisioning | |
| US20040083467A1 (en) | System and method for executing intermediate code | |
| 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 | |
| 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 | |
| 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) | |
| US11989569B2 (en) | Unikernel provisioning | |
| US20150186168A1 (en) | Dedicating processing resources to just-in-time compilers and instruction processors in a dynamic translator | |
| Chiba | Optimizing Boot Times and Enhancing Binary Compatibility for Unikernels | |
| CN114115938A (en) | Linux cross-architecture file running method based on QEMU | |
| Anwar et al. | Dynamic binary translation in a type-II hypervisor for Cavium Octeon MIPS64 based systems |
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 |