Linux containers vs. VMs: A security comparison

More vulnerable than virtual machines? In fact, containers have some security advantages

1 2 Page 2
Page 2 of 2

Gaining initial access. The attacker needs a point of entry into the system, ideally to a point as “deep inside” as possible and with the highest possible privileges. One potential channel is to find a vulnerability in a public-facing endpoint such as a Web server. Since these often run as a privileged user, under an architecture where each VM runs multiple services, such an attack can be very powerful. Containerizing the Web server, or isolating it in its own VM, helps limit the attack by separating the Web server process from other processes. User namespacing separates the root user of the container from the root user of the host OS. For this reason containers offer better protection at this stage of an attack than a legacy VM application, and they are probably on a par with VM architectures that use separate VMs by function.

Server vulnerabilities happen, but the much more common attack point is to gain access to a user’s workstation, leveraging browser vulnerabilities or social engineering. This might get attack code running inside the corporate network, if that’s where the system is located; ideally (from the attacker’s standpoint) the company has done a poor job of segregating the production and employee networks.

Inside the corporate network or not, the malware can monitor the user’s activities and look for credentials for other systems that might be better attack points. If the user is an administrator or other privileged user, with access to sensitive systems, the attacker has hit the jackpot. The security postures of containers and VMs (at the server level) are largely the same here, although there are interesting applications of both VM and container technology at the individual workstation that try to better secure the browser.

Move laterally from system to system. Unless the first system attacked has what the attacker wants -- unlikely -- he will try to spread the attack through the corporate network. The most effective entry point into servers (from, say, an infected workstation) would be a vulnerable host OS for containers or Type 2 VMs. If the attacker compromises such a host and gets root, he will be able to access every container or Type 2 VM on the system. The equivalent attack on a Type 1 virtualization host would be much more difficult, due to the hypervisor’s much smaller attack surface. Direct attacks on interfaces exposed by services have similar attack surfaces for services in containers and VMs. 

Once inside a server, the attacker will want to move throughout that machine and to others. Here containers are more vulnerable to OS attacks, due to the larger attack surface presented by the OS system call interface. The attacker’s ability to extend his reach by calling out to other services depends on how well network controls are applied. If the network is open, the attacker will proceed to search for other systems. However, strict network controls (like those provided in the Apcera Platform) can help limit access in containerized systems.

Escalate privilege. If the attacker already has administrative credentials, especially with access to server side management interfaces (hypervisor management, container management, host OS access), neither approach can provide much protection. In this case the attacker has pretty much won.

Inside a server, the interface between containers and the kernel makes for a larger attack surface than the interface between a VM and a hypervisor. This vulnerability is mitigated by user namespaces, which constrain the power of root inside the container. Privileged access inside the container can affect the app itself and potentially shared resources (like data sources), but can’t access root resources outside the container.

Again, if the VM architecture has many services inside a single VM, privilege escalation can cause more damage, since code running as root inside one service will effectively have unlimited access to the other services. Similar logic argues against container architectures with multiple processes or services inside the same container.

Find sensitive data. Services running together inside a VM often share or have similar access privileges to data, so they're vulnerable to an attack. VMs often have virtual disks used by many processes. On the other hand, the container practice of “no data inside containers” helps isolate and protect sensitive data. Microservices architecture standardizes such access with RESTful APIs that can have standardized controls (such as authentication and authorization) applied to them. Other controls, such as Apcera’s Semantic Pipelines, can provide advanced security between containers and data sources.

Embed a long-lived presence. Both VMs and containers can be booted from trusted repositories, so they are similar in their resistance to an attacker infecting an image with malware that survives across a boot. The underlying host OS, if one is present, may be vulnerable to such an attack. Mechanisms are evolving for secured system boot, starting from an embedded hardware root of trust, that can prevent these kinds of attacks, but they are not yet widely deployed. The long-lived nature of VMs gives containers an edge here, since the container may come and go before the malware has a chance to do much.

Do damage. This is similar to finding sensitive data, but with write access: The attacker wants to change something, wipe a disk, insert transactions, and so on. Container-based microservices architectures encourage better isolation and, hence, better protection against damage than typical VM systems.

Exfiltrate data. A more closed and closely controlled network of containers (such as that in the Apcera Platform) has a smaller attack surface for exfiltration than one with open VMs. However, the ability to apply the controls is key. VMs can be similarly protected (at least VM to VM, if not between services inside a single VM) by appropriate configuration of networking infrastructure, but the process is often manual, tedious, and error prone. Similarly, a container network without inherent platform support for network controls would be difficult to make both operational and secure.

Comparing container and VM security yields no runaway winner. Much depends on how the containers and VMs are used, and specifically on the architecture of the applications they support. In this regard, containers often have an edge because they are more likely to be used for new applications. In some sense it is unfair to compare VMs running within legacy architectures with containers and microservices, but that is often the reality of how they are used. Perimeter controls cannot contain modern attacks. We need to evolve our approach to security and adapt to new architectures. Containers, along with solid platforms for securing and managing these architectures, will be an important part of that evolution.

Jim Reno is chief security architect at Apcera.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

Copyright © 2016 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2