Linux containers vs. VMs: A security comparison (InfoWorld) [LWN.net]

Over at InfoWorld, Jim Reno compares the security of virtual machines (VMs) and containers. "Which is more secure?" is a question that is often asked, but the answer, of course, is "it depends". Reno analyzes the attack surface of each to help in the choosing between VMs and containers. "Many legacy VM applications treat VMs like bare metal. In other words, they have not adapted their architectures specifically for VMs or for security models not based on perimeter security. They might install many services on the same VM, run the services with root privileges, and have few or no security controls between services. Rearchitecting these applications (or more likely replacing them with newer ones) might use VMs to provide security separation between functional units, rather than simply as a means of managing larger numbers of machines. Containers are well suited for microservices architectures that “string together” large numbers of (typically) small services using standardized APIs. Such services often have a very short lifetime, where a containerized service is started on demand, responds to a request, and is destroyed, or where services are rapidly ramped up and down based on demand. That usage pattern is dependent on the fast instantiation that containers support. From a security perspective it has both benefits and drawbacks."

to post comments

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 0:42 UTC (Fri) by spender (guest, #23067) [Link] (10 responses)

In case you're curious why this article doesn't mention grsecurity at all, as virtually any other article on Linux containers does (for instance this 122 page paper: https://www.nccgroup.trust/globalassets/our-research/us/w...):

"Jim Reno is chief security architect at Apcera."
https://www.apcera.com/solutions/modern-architectures

-Brad

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 2:11 UTC (Fri) by pabs (subscriber, #43278) [Link] (4 responses)

Can you expand on what Apcera actually provides?

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 7:28 UTC (Fri) by malor (guest, #2973) [Link] (3 responses)

Brad does grsecurity; he may not be able to usefully talk about Aptera.

Further, it strikes me that this Infoworld article is more or less an advertising piece; it's got some useful info in it, but slanted toward selling the author's product. Any further discussion about it just helps him advertise.

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 20:44 UTC (Fri) by rahvin (guest, #16953) [Link] (2 responses)

"Purchased" articles are common these days. It unfortunate because now you need to vet any information you receive from any publication or article because they may have been paid to write the article.

It's gotten so bad I pretty much ignore a lot of stuff that might be valid because I suspect it's a paid article advertisement masquerading as an actual review. Even forum comments are getting this way with companies and governments paying SEO type companies to spam commenting systems with subtle advertising.

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 21:43 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

The correct term is called 'Native Advertising'.

This is different then things like product placements you see in television in movies. Rather then placing products or adding ads to a article.. the entire television show segment or article is written for a specific customer.

Everybody needs to understand very well that when you are dealing with the vast majority of television, radio, or other media that _you_ are _not_ the customer. A customer is a person that pays a business for a service. The customer of most media is advertisers.

And the articles and television programs and other such things.. these are not the products. Those are just a means to a end. The actual product is people's attention.. peoples 'eyeballs' and 'ears'. The articles are just there to entice you into seeing their advertising.

As the reality bubble around online advertising is collapsing and old media is dying these places are becoming more and more desperate for revenue. The customers are realizing that the quality of product they are being sold (people's attention) is just not there and the quantities of views are pure fantasies in many cases.

As desperation increases so then the ethical barriers begin to fall.

Originally some websites would allow 'sponsored content' that would have disclaimers at the top and bottom and was different in appearance. Used different fonts, different placement, different styles, etc.

But that was probably 5 years ago.

Nowadays even very mainstream and relatively respected media outlets will actually sell _writers_ and _editors_ time to other companies to make sure that even the writing style is indistinguishable. They will take the content from the advertiser and rewrite it to match their magazine or website or whatever.

It's very shitty behavior and is only going to get worse.

That is why outlets like lwn.net are so important. Because we pay them money for content WE are the customers. Not advertisers. They write the articles for US.. for our benefit.

This is unfortunately very rare nowadays.

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 26, 2016 14:36 UTC (Thu) by jospoortvliet (guest, #33164) [Link]

I agree with your analysis, just am a bit less negative about it: if we don't pay directly, sites have to earn in other ways. Native advertising can be ok if it is made clear what it is (yes that often goes wrong) and is done with some editorial integrity (that really is possible!).

I am sympathetic because I see there a big gray area. As KDE volunteer I occasionally wrote articles about KDE for magazines. Obviously I didn't get paid - they got free content to put ads around, I got to promote my project. And lwn editors get travel and hotel support to visit events and write about them. This, too, is money to promote those events.

And then there is the thing where a journalist is involved in or just a fan of a project - that makes them less than neutral too.

Yes those things are different. But not THAT different. And they can be done right and without horrible side effects. I think the same goes for native advertising. It can be a disaster, abused. But not always I think

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 2:41 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Why should it? grsecurity is not a guarantee against exploits. It provides hardening, but not assurance.

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 11:06 UTC (Fri) by PaXTeam (guest, #24616) [Link]

we have actually some features that guarantee that entire bug classes are no longer exploitable (for privilege escalation that is, reporting+reaction usually means some form of DoS but that's inevitable).

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 7:49 UTC (Fri) by corsac (subscriber, #49696) [Link] (2 responses)

Another reason might be that grsecurity doesn't really have any specific support of namespaces/containers, whether in RBAC or elsewhere. The chroot restrictions apply, obviously, and the generic hardening against userland too.

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 11:17 UTC (Fri) by spender (guest, #23067) [Link] (1 responses)

I have to say this is a really odd comment for the maintainer of grsecurity on Debian to make.

It's true that grsecurity doesn't support mount namespaces in RBAC, like several other access control systems. The difficulty being that RBAC is designed to be used system-wide and doesn't yet permit individual per-namespace policies. Mount namespaces allow for filesystems to exist which cannot be seen via the global namespace, so there's no way I can see yet for us to construct a path to represent those unreachable names when logging to dmesg, and it's not possible to have one gradm see all the files involved at load time. I also don't like the user experience of requiring individual gradm usage in each container, particularly when that's generally automated.

It's not true however that grsecurity has no namespace support. There's special handling in some of the chroot features for pid /mount namespaces, all of the code is user-namespace aware, and the net/cgroup namespaces are pretty orthogonal to anything in grsec. Several non-configurable changes also provide additional security for containers, requiring CAP_SYS_ADMIN for /proc/sys writes, for instance.

I know of many people using Docker with grsecurity -- from a read of a recent github issue about it, it seems they've also resolved an incompatibility that required disabling two chroot protections at runtime. If anyone has any compatibility issues with containers, they're of course welcome to report that on our forums (or point us to relevant Docker github issues) where we can help explain things and come up with more secure alternatives.

Finally, the reason it should have been mentioned (generally this would have happened in the paragraph starting with "Finally, the process to kernel interface (for system calls) is large and exposed in every container", or even seccomp at least) is why anyone using containers or shared hosting uses grsecurity: to protect the kernel from users and strengthen the separation between one potentially compromised user and other customers. Obviously it's no guarantee, there are still logic bugs and other one-off failures, but what is a guarantee is that any public memory corruption exploit that has a chance of working against grsecurity or demonstrates new exploit techniques will have its techniques and bug classes killed off in a short period of time. Anyone's welcome to look into our history to see many examples of this (shadow vsyscall hardening, KSTACKOVERFLOW, RANDKSTACK, STACKLEAK, USERCOPY, some very recent USERCOPY enhancements, STRUCTLEAK, removal of thread_info from the stack, MODHARDEN, etc etc).

-Brad

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 20, 2016 11:54 UTC (Fri) by corsac (subscriber, #49696) [Link]

In case my original comment wasn't interpreted the way I intended (that's at least the case for Brad, so maybe also for others), I wasn't implying at all that grsecurity was incompatible with containers, quite the opposite actually.

My point was more like grsecurity and containers are orthogonal to each others, and that might be the reason (pure speculation though) the original article didn't mention it.

The one place where they're not orthogonal features is with RBAC (which can be used to isolate processes a bit like containers do), and that also means it's really hard to have specific namespace support.

I stand corrected about the chroot restrictions though, that's nice.

And obviously, like Brad said on the last paragraph, since you share the same kernel on all the containers, you actually really want to protect it against the various userlands, and thus having a hardened kernel is definitely a good idea here (on top of generic container hardening like capabilities dropping, seccomp etc.). I do run some (LXC, not docker) containers and I'm glad I'm running them on a grsecurity kernel.

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 21, 2016 17:01 UTC (Sat) by dps (guest, #5725) [Link] (1 responses)

While the infoworld article does mention one or two products, to the exclusion of other similar products, a tad too frequently, it is not completely awful. I did completely fail to note that exposing internal bits of services increases the attack surface, so might be a bad idea.

Containers do look interesting as a way of making it harder to gain control of a system. Once a system is owned then I would be much less worried if was a "real" VM, or separate real box, with sharply limited access to the resources I want to protect. Even VMs tend to feature a privileged entity with visibility and control of all the VMs, so genuinely separate systems are more secure.

There is no reason not separate services onto separate VMs, or even genuinely separate hardware, and use containers as a security measure on those systems. I know genuinely separate hardware is neither modern nor clowd.

A drop-safe system log message recorder should use completely separate computers, connected by a narrow and very limited connection, and *not* either containers or VMs. You can't attack the secure log recording via the network because the box doing it has no network connection. (I am imagining a single rack mount box with 2+ systems on a chip and some secure time on it . Aim for a profit and price of ~$300.)

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 23, 2016 17:05 UTC (Mon) by zlynx (guest, #2285) [Link]

The logger can be jammed though. Unless precautions are taken like forcing 100 Mbps switch ports to the servers and 1 Gbps to the logger. Or some other form of flow control.

Linux containers vs. VMs: A security comparison (InfoWorld)

Posted May 26, 2016 6:33 UTC (Thu) by xophos (guest, #75267) [Link]

This sounds to me like "Cobra oil or rattlesnake oil, a health benefit comparison".
While sandboxing through containers or VMs might make some atacks more difficult, it opens up a completely new attack vector: attacking the sandbox itself.
The complexity of the whole system is much higher, and complexity is the foe of security.
Minimalism and careful auditing will help, but they have a high cost in competent work.
Snakeoil is so much easier and sounds so much better.