SCONE Secure Linux Containers Environments with Intel SGX

SCONE Secure Linux Containers Environments with Intel SGX 

From the provider’s perspective, they don’t trust their users so they use virtual machines to isolate users from each other as well as from the host infrastructure. One thing to note though is that virtual machines only provide a one way isolation they protect the provider from the users but they do little to protect users from potentially malicious administrators that log on to the machines and do some memory dump for example.

From the perspective of the users. The applications are trusted but if I run my application on someone else's computer or someone else's cloud I currently have no choice but to also implicitly trust the cloud provider

To address this issue we can use intel sgx

What sgx gives you is the ability to construct a trusted environment on top of the untrusted cloud that is enforced by hardware. As we already known from lecture, the contents inside enclave are protected and unable to be either read or saved by any process outside the enclave itself, including processes running at higher privilege level. Sounds like a good fit to solve our problem. 

Two main challenge of Integration 

So to achieve our goals to integrate sgx with container we identified two main challenges that we have to overcome. The first one of which is how much code should be included in the enclave. So we should minimizing the side of the trusted computing base inside an enclave while supporting existing applications in secure containers.
Next issue is we need to maintain a low performance for containers. Based on current implementation of sgx, a thread must exit the enclave to system calls. Such enclave transitions come at a cost—for security reasons, a series of checks and updates must be performed, including a TLB flush and memory-based enclave arguments must also be copied between trusted and untrusted memory, which cause a big overhead.

First challenge solution 

There are 3 major design. The left one is the haven’s design. It throw the whole OS into TCB to support windows program execution.  What that gives you is a potentially large TCB with potentially many vulnerabilities. On the other hand haven has a small interface to the outside world which is easy to monitor and secure the communication between inside and outside. The one in the middle, however have a opposite design. It literally leave all stuff outside which can have a minimal TCB and reduce the possibility of having vulnerability. But the communication between outside and inside could be extremely hard to monitor given malicious os control syscalls and then controls return result from kernel mode which could do malicious thing inside. And finally the right one this is the SCONE’s design, basically the balance of two previous design. While this design does not rely on a minimalist external interface to the host OS, but the shield libraries can be used to protect a security-sensitive set of system calls: file descriptor based I/O calls, such as read, write, send, and recv, they all are shielded by transparently encrypting and decrypting the user data

Second challenge solution

To address this issue, scone implements m:n threading model to avoid the cost of unnecessary enclave transitions. M enclave bound application threads are multiplexed across N OS threads. When an application thread issues a system call, SCONE checks if there is another application thread that it can wake and execute until the result of the system call is available. Also SCONE offers container processes an asynchronous system call interface to the host OS. Its implementation uses shared memory to pass the system call arguments and return values, and to signal that a system call should be executed. System calls are executed by separate threads running in a SCONE kernel module. Hence, the threads inside the enclave do not have to exit when performing system calls. To give a better understanding of what actual happen, i will a give a simple exampleSo this is the scone architecture. Which consists of a enhanced c library to minimize tcb and asynchronous systems calls and user space threading reduce number of enclave exits and Network and file system shield to protect user date

Overall Architecture

In conclusion

SCONE is a secure container mechanism for Docker that uses the SGX trusted execution support of Intel CPUs to protect container processes from outside attacks.

It is now support running C, C++, Fortran, GO, Java, Python, PyPy, Node, R, Rust program without change of source code.

And Quote from SCONE team “What we are focusing on in the SCONE platform is to help application providers to move application into intel sgx or other alternatives” “We want to make it as transparent, as simple as possible so you get additional security without engineering effort ” 

Sounds great right?

My personal opinion

Based on my personal experience on SCONE, it is not transparent enough. To minimize the TCB, SCONE uses musl as generic libc which could cause compilation issue on some application and scone doesn’t support fork(), exec(), clone() which diminish its usability since many processes require these functions like the installation of tensorflow.

And they support dynamic library which means you can execute code come from untrusted environment, and i don’t think it is secure

And one thing i think which is most important is scone is not open sourced SCONE implements their own scheduler, syscalls, file shield and many other staffs. If we cannot trust functionality provided by OS why should I trust SCONE? 

However, SCONE is still one of best secure container with sgx you can actual use. If you are interested moving your application into sgx, you should definitely try SCONE

Reference :
[1] https://www.usenix.org/system/files/conference/osdi16/osdi16-arnautov.pdf
[2] https://sconedocs.github.io/