Abstract—Linux containers is a very important and useful system because of the need for few resources consumption, fast startup times, and high I/O performance especially when it’s compared to virtual machines (VMs) on hypervisors, in multi-tenant environments. This paper is focused on how Linux containers can be secured from attackers who enforced through software kernel mechanisms, by using Intel SGX technology from outside attacks on Docker. This mechanism is called SCONE. SCONE is useful because Linux containers (which are managed by Docker or Kubernetes) do not provide guarantees concerning the security of application data within containers. SCONE offers a secure C standard library interface that encrypts/decrypts I/O data in order to diminish the execution repercussion of thread synchronization and system calls within SGX enclaves and a minimized trusted computing base (TCB). SCONE also supports user-level threading and asynchronous system calls. This paper through the analysis and studying shows an evaluating that it protects unmodified applications with SGX.
Keywords—SCONE SGX, Linux containers, security of Linux containers, TBC size, enclaves
Many multi-tenant environments use Linux containers in order to confer performance seclusion of applications. The Docker Swarm is used for development (or Kubernetes) and Docker for packaging of containers. Currently, virtualization container-based is widely used and has become trend. However, containers seem to have better performance compared to improved hardware virtualization (VM) in hypervisor. Containers provide faster start up time, better I/O throughput and better delay. They undoubtedly provide uncertain security benefits than virtual machines (VMs). This is due because of the fact that there is the need for the host operating system (OS) kernel to protect a larger interface and usually uses only software mechanisms for isolation.
Mainly, container seclusion mechanism what they actually do, is to protect the environment from unreliable containers. Tenants from the other side, are protecting not only unreliable mechanisms but also are providing covertness and probity for their application data from unauthorized access from higher-privileged system software as well as the core of the operating system (OS) and the supervisor. Malicious users are primarily looking for unprotected spots in virtualized system software for attacking or maybe they are staking at the authorized administration accreditations.
Lately, was achieved the hardware mechanism to protect in user-level software from the widely preferential system software. Specifically, in 2015 Intel promoted to the market the Software Guard eXtensions (SGX) for their own CPUs. The Software Guard eXtensions (SGX) provide support for secure enclaves. The function of an enclave is to protect application codes and data from entry by other software and to provide higher-privileged software. Into the enclave page cache memory (EPC), there are memory pages which correspond to an enclave, in which there is no possibility for access using code outside of the enclave. So, SGX is recommended as an ideal choice for the security of containers, covertness and probity of the data are assured because the application process of a container can be executed inside an enclave.
The SGX mechanism which is providing security in containers is required to cope up two basic problems. The first problem which this mechanism is facing up is the improving the size of the trusted computing base (TCB) inside an enclave and the protection of existing applications into secure containers. The second problem that might need to face up is the challenge of conservation of low burden overhead in for security of containers by exploiting the possibilities of SGX mechanism.
The trusted computing base (TCB) is a factor which employ in general because of it size. According to other studies the TCB occupies huge size in Windows applications where is executed into enclaves, because of the libraries and the operating system (OS). An appropriate protection for TCB is necessary because otherwise a malicious user may entry into the application data or jeopardize the confidentiality, for that reason is rendered necessary to keep a minimized size of a container’s TBC into an enclave.
A problem that arises from the use of enclaves is its general attribution which resulting by the OS kernel which is not trustworthy. This because of enclave code which cannot implement system calls. The function of an enclave thread is to copy arguments from memory and abandon the enclave before a system call. The transfer of those threads becomes very costly. The reason for this is that these threads perform saving and restoring the enclave’s carry out situation. One more reason which is responsible for the delay except from cache misses, is cache lines which is necessary to be decrypted when transferred from memory. In addition, out of the enclave page cache (EPC) provoke costly page errors.
In order to keeping up a minimized TCB size for secure containers, firstly is notable that containers typically perform network duty (i.e. NGINX, Redis, Memcached and Apache) therefore, is considered essential small interface for backing of the system. The communication is achieved by the outside through network reception or stdin/ stdout streams, secluded or evanescent file systems are used, also do not enter other I/O devices directly. For lightening of secure containers, the enclave code can enter into the memory outside of the enclave without the burden of the performance. Nevertheless, remains costly the overhead of access (whether for leaving or entering) the enclave high system calls frequency in applications.