III. SCONE MECHANISMThe main goal of this study is to provide security in containers on the top of an untrusted operating system. Actually, services which are containerized need to protect by attackers from secure containers. Also, secure containers need to suit in Docker’s container environments. In order to do so, it is necessary to secure container images by system administrators using Docker in a trusted environment (e.g. EPC memory, operating system) and execute secure containers in an untrusted environment (e.
g. DRAM memory). A. ArchitectureThe Secure CONtainer Environment (SCONE) design offers a an interface which is rely on system calls to the central operation system (OS), which is proteced from malicious users.
SCONE mechanism also execute logic checks and copies all based on memory returning values into the enclave while initially arguments have go through the application. This is similar of what was mentioned above that is operating system’s kernel which has the feature of protection of malicious users. SCONE also offers encryption and authentication of data in order to protect probity and trustness of data that were processed through files descriptors. In the figure 1.
below there is an overview of the SCONE architecture. In order to avoid the enclave’s transitions, (where cause performance overhead) that are not necessary SCONE mechanism is proving threading implementation. Enclave bound application threads are multiplexed across operating system’s (OS) threads. SCONE mechanism is configured is configured in such a way it can manage systems calls of the systems. Specifically, when a system call is incuredd by an application thread, SCONE is checking if some other application thread that it is available and can execute until the result of the system call is available. As it was mentioned before, SCONE mechanism can handle system calls. This feature is called asynchronous system calling. So SCONE produce container processes with asynchronous system call interface to the central operating system.
SCONE’s implementation use a shared memory for copying system call argument and returning the results back and to signal the implementation of the system call. Into the SCONE kernel module system calls are implemented by individual threads running. Therefore, threads that are existing into the enclaves there is no need to be out of the enclave when system calls executed. SCONE mechanism also, is related with existing Docker container environments, and guarantee that secure containers are suitable for the Linux containers standard. The cantra l operating system need to use a Linux SGX driver in order to increase the performance, a SCONE kernel module. Is remarkable that, SCONE mechanism does not need any functionality from the Intel Linux SDK except from the Linux SGX driver.
B. External interface shieldingTrusted operating systems are is very widespread and there is a lot of demand for them, especially, from popular services, such as Memcached and Redis. This is happens because such services need to communicate with other tasks through the TCP channels which are not encrypted(this means without the use of TLS), and export to stdout and stderr directly.
In order to protect those services into containers, which provide security, SCONE offers special functions into set of shields. The first thing that this set of shields is deals with is the avoidance of low level attacks as for example the operating system kernel controlling buffer sizes and pointers go through the service. The second thing that the set of shields is focuse on is the guarantee of probity and trustness of application data that passed through the operating system.
This set of shields is provided by a specific shield library to the services. SCONE provide this set of shield that was mentioned above for the encryption of console streams, encryption of files and for the encryption of communication channels through TLS.C. Asynchronous system callsEarlier mentioned, that as long as system calls cannot be to be dealt with into the enclaves, are forced to be executed with the help of calls to functions out of them (enclaves).
Briefly, this means that the thread process is necessary to pass memory-based arguments out of the enclave memory (DRAM) which is unprotected and implement the outside function to issue the system call. After the system call is completed and return need to go back to the enclave and pass the results from the external memory to the enclave’s memory. Such system calls got a big performance overhead for that reason is suitable only for application with a low system call rate. To face this problem, SCONE mechanism offers an asynchronous system call interface solution. This interface produce multi-producer and multi-consumer queues which are request queue and a response queue. By placing a request into the request queue, system calls are executed.
Into the SCONE there is a kernel module that receive and process those system call requests and all these are handled by an operating system thread. After completion of system call the operating system thread enter the result into the response queue.In conclusion, enclave implementation manage system calls also, guarantee that pointers going through by the operating system to the enclave and do not point to enclave memory. So through all this, is provided protection to enclaves from memory-based Iago attacks and is executed for all shield libraries. D. Docker integrationDocker is the most popular container platform which is used a lot. That’s why it is a good choice for SCONE’s implementation.
There is the possibility in the future to be compatible not only with Docker but with open container platform also (rkt (CoreOS)). SCONE mechanism produce secure containers which is composed of a single Linux process that is secured by an enclave, but from the other side is indiscernible from a Docker container (for example based on the shared central operating system kernel for the implementation of system calls).
