Posted on 07/17/2018 4:47:26 AM PDT by ShadowAce
Are virtual machines (VM) more secure than containers? You may think you know the answer, but IBM Research has found containers can be as secure, or more secure, than VMs.
James Bottomley, an IBM Research Distinguished Engineer and top Linux kernel developer, writes:
One of the biggest problems with the current debate about Container vs Hypervisor security is that no-one has actually developed a way of measuring security, so the debate is all in qualitative terms (hypervisors 'feel' more secure than containers because of the interface breadth) but no-one actually has done a quantitative comparison.
To meet this need, Bottomley created Horizontal Attack Profile (HAP), designed to describe system security in a way that it can be objectively measured. Bottomley has discovered that "a Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."
Bottomley starts by defining Vertical Attack Profile (VAP). This is all the code, which is traversed to provide a service all the way from input to database update to output. This code, like all programs, contains bugs. The bug density varies, but the more code you traverse the greater your chance of exposure to a security hole. Stack security holes exploits -- which can jump into either the physical server host or VMs -- are HAPs.
HAPs are the worst kind of security holes. Bottomley calls them, "potentially business destroying events." So, how do you measure a system for HAPs? Bottomley explains:
The Quantitative approach to measuring the HAP says that we take the bug density of the Linux Kernel code and multiply it by the amount of unique code traversed by the running system after it has reached a steady state (meaning that it doesn't appear to be traversing any new kernel paths). For the sake of this method, we assume the bug density to be uniform and thus the HAP is approximated by the amount of code traversed in the steady state. Measuring this for a running system is another matter entirely, but, fortunately, the kernel has a mechanism called ftrace which can be used to provide a trace of all of the functions called by a given userspace process and thus gives a reasonable approximation of the number of lines of code traversed. (Note this is an approximation because we measure the total number of lines in the function taking no account of internal code flow, primarily because ftrace doesn't give that much detail.) Additionally, this methodology works very well for containers where all of the control flow emanates from a well known group of processes via the system call information, but it works less well for hypervisors where, in addition to the direct hypercall interface, you also have to add traces from the back end daemons (like the kvm vhost kernel threads or dom0 in the case of Xen).
In short, you measure how many lines of code a system -- be it bare metal, VM, or container -- uses to run a given application. The more code it runs, the more likely it is to have a HAP-level security hole.
Having defined HAPs and how to measure it, Bottomley then ran several standard benchmarks -- redis-bench-set, redis-bench-get, python-tornado and node-express -- with the latter two also running the web servers with simple external transactional clients. He performed these tests with Docker, Google's gVisor, a container runtime sandbox; gVisor-kvm, the same container sandbox using the KVM, Linux's built-in VM hypervisor; Kata Containers, an open-source lightweight VM; and Nabla, IBM's just released container type, which is designed for strong server isolation.
Bottomley found Nabla runtime had a better "HAP than the hypervisor contained Kata technology, meaning that we've achieved a container system with better HAP (i.e. more secure) than hypervisors."
It wasn't just IBM's project, though, which proved more secure. He also found, "Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."
GVisor was another story. At best, gVisor had results about even with Docker use case, but in one case it was, significantly worse. Bottomley speculates that's because "gVisor tries to improve containment by rewriting the Linux system call interface in Go. However, no-one has paid any attention to the amount of system calls the Go runtime is actually using, which is what these results are really showing." If that's the case, Bottomley thinks a future version of gVisor could be rewritten to be much more secure.
The real point, though, isn't which technology is more secure per se. It's that, for the most severe security problems, containers and VMs have about the same level of security. Indeed, Bottomley thinks, "it is perfectly possible to have containers that are more secure than hypervisors and lays to rest, finally, the arguments about which is the more secure technology."
"The next step," he continued, "is establishing the full extent of exposure to a malicious application and to do that, some type of fuzz testing needs to be employed"
In addition, Bottomley's work is only the start. He's shown it's possible to objectively measure an application's security. As he said, "I don't expect this will be the final word in the debate, but by describing how we did it I hope others can develop quantitative measurements as well."
IF data are permitted to reside or be handled ON the endpoint, then utilize a container.
IF bandwidth is good, VDI, else, NOT!
NET: use both like my DoD customers
Unlocked doors or holes in the side of your house.
Which is more secure?
In short, you measure how many lines of code a system -- be it bare metal, VM, or container -- uses to run a given application. The more code it runs, the more likely it is to have a HAP-level security hole.
#MeToo
> In my opinion all assumptions derived from this are suspect. This measurement presumes all programmers are equal, and all code auditors are equal, and all code up the chain has been equally programmed and audited.
It's worse than that. Maybe one could posit that, "on average", more code means more bugs, but only over a huge amount of code.
The problem is that people will take this metric and apply it to small individual cases. An average generalization that only makes sense over millions of lines of code simply cannot be applied to individual cases.
Consider: "On average", adult men are (say) 5'8" tall. And how many men in any given population are 5'8" tall? A tiny percentage. All the rest are taller or shorter, and that's the vast majority.
This HAP metric is way oversimplified. I would regard this as a concept that can be worked into the executive summary of an expensive product or service.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.