A Look at SCONE: Secure Linux Containers in Untrusted Environments with Intel SGX
For sensitive containerized workloads in the cloud, good security practice requires not only safeguards from outsider intrusion but also protections from superusers of the cloud system itself. Does your cloud provider have snoopy admins? Or sloppy security? Or just regulatory compliance more lax than your own?
Such was the concern that propelled a group of researchers to create SCONE (Secure Linux Containers on Intel SGX), presented at the USENIX Symposium on Operating Systems Design and Implementation last year. The architecture offers a way to run containerized trusted applications on untrusted cloud services through the use of Intel SGX (Software Guard Extensions) built into that company’s Skylake architecture-based chips. The container itself is equipped with the software to interface with SGX.
While SCONE appears to offer a workable solution, getting a SCONE deployment to work, and to work correctly, can be quite the undertaking, and still won’t offer full security protection, noted Jess Frazelle, Microsoft Azure engineer and noted container security expert, during a recent talk about the USENIX paper for the Papers We Love event in New York City.
“There are a lot of things that the user has to handle in implementing this, which makes it very hard to do. And very hard to do well,” Frazelle warned.
Nonetheless, the technology is worth taking a look at Last month, Microsoft Azure began offering Trusted Execution Environments (TEE), also known also “enclaves,” that block access to data to anything other than authorized code, including any superuser privileges inherent in the host server. Conceivably it would be possible to use SCONE on Azure for protected operations.
TEE works this magic through portions of server memory protected by SGX. The SGX enclave “shields application code and data from accesses by other software, including higher-privileged software,” the paper’s many authors note. The “enclave” leveraged for the project is, on the chip, an enclave page cache (EPC), a partition of memory controlled by a set of 18 instructions and cannot be accessed by outside code.
When planning for SGX’s “trusted compute base,” which would run inside the enclave, SCONE researchers were led by two chief requirements: One was to keep the code base as small as possible, in order to minimize the attack surface. The other would be to maintain performance by not introducing excessive latency, which was inherent in the “enclave” model insofar that any system call to made the kernel would necessitate the thread jumping outside the enclave, with all the attendant memory copying involved.
“This paper is all about trade-odds, really,” Frazelle said. Much of the SCONE work is balancing security against performance.
“If everything is in the sandbox, then there is no sandbox.” #PapersWeLove w @jessfraz #security pic.twitter.com/omf3T8Cblc
— Joab Jackson (@Joab_Jackson) October 9, 2017
Originally, the researchers looked at Microsoft’s Haven model for secure operations. This approach, however, involved placing most of the operating system within the container, which, for all the libraries it would require, would not be feasible for Linux. The code base would be too large and it would add latency. Besides, if there was a vulnerability within the enclaved OS, the whole system could essentially be compromised, “It might work for Windows, but for Linux, it was not a good thing,” Frazelle said.
The researchers also investigated the other extreme, namely stripping out all the libraries for a minimal install-base, leaving a handful of system calls that would be needed to call the OS. This approach too, however, had its issues, as it would place a greater burden on protecting data and operations that fell outside of the purview of the enclave.
The three possibilities for secure container design (USENIX paper).
The approach they settled on for SCONE was a combination of the two. The heavily used C Standard Library was enclaved, eliminating the need for many outside system calls. SCONE provides a “network shield” for all socket operations in and out of the enclave, providing for each connection a TLS handshake and encryption/decryption, using the private key and certificate from the container’s file system.
An “asynchronous system call mechanism” was also introduced. “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,” the paper stated.
This approach, the researchers felt, yielded the optimal results. Under SCONE, a set of applications — Apache, Redis, NGINX, memcached — ran at about 0.6 to 1.2 times of native execution. Due to a quirk in how Memcache handles encryption, that software actually ran faster in the enclaved environment.
In Every Dreamhome a Heartache
One immediate issue at hand is that every application will perform this well, Frazelle pointed out. The asynchronous system call is performantly expensive, so apps that make lots of system calls will suffer badly under enclave. “Anything that passes system calls in and out super fast will be super slow with this,” she said. SCONE comes with multi-threading mechanisms to lessen the pain, though performance will be particularly painful of single-threaded applications, such as Redis.
Memory page faults also weigh down performance, as do L3 cache misses, which can be up to 12 times as slow from the enclave. “That’s really friggin’ bad,” Frazelle reminded the audience.
“Although you are gaining a secure place to run a container, you are taking a huge hit on performance,” she said, adding that she’d expect performance to improve more over time as more people work on the code base.
There are other trade-offs as well. One is the investment on the part of the users.
“There is a lot of things to think about when it comes to what you are doing with this,” Frazelle concluded. SCONE promises that the original application code can run unaltered in the enclave, but still plenty of work will be needed to outfit systems to run SCONE.
All the software for setting up the enclave must be installed within the Docker container itself. An enclave kernel module would also be needed to process the system calls. SCONE also doesn’t support the fork system call, limiting the range of applications that could be used.
The complexity of passing the system calls and doing the necessary encryption and decryption adds extra attack surface, Frazelle pointed out. “If there are any bugs that you are putting in that enclave then you are screwed,” she said.
Microsoft is a sponsor of The New Stack.
