Security of LXC compared to OpenVZ

Question

For years, I'm now using OpenVZ on my server, but support discontinued for Debian and Ubuntu, current releases seem to focus on LXC now, which is not a bad idea from the point of comfort.

But what about security? I remember I read once that LXC doesn't provide the same level of process and container separation than OpenVZ does. Unfortunately, I cant find the document anymore, but I agree there might be some security issues at least in the default configuration of LXC. For example, with a completely customized rootfs I managed once (in an older version of LXC) to change the host's terminal from an LXC container using chvt 1 and pressing Ctrl+C ended in a restart of my X11 environment when I tried to reproduce it today. I know, all container solutions use the same kernel and a kernel hack can lead to a container breakout, that's not what I ask. But it shouldn't be that easy to influence the host or other containers from a container.

How much security can I expect from OpenVZ and LXC?

My server exposes some guest ports to the internet, so I really care about this aspect, but I have to make a decision because the currently used tools need to be upgraded. Using KVM or similar is not an option since my server has a low-performance CPU.

PS: I'm speaking about the real OpenVZ implementation with vzctl 4.7.2-1. Some newer implementations of vzctl use LXC techniques.

Answer 1

[2023 important update]

Things have taken a turn, and now I recommend LXC over OpenVZ.

LXC has become more mature. Unprivileged containers in LXC are significantly more robust and secure now. And with the introduction of LXD and Incus, using LXC has become much more user-friendly.

With native support for OVS/OVN, the LXC network management has become equally easy and secure.

It's worth noting that LXC has always been available in the mainline Linux kernel, eliminating the need for custom kernels and making it faster to receive security fixes.

On the other hand, OpenVZ is struggling to keep up with Linux kernel development. OpenVZ 7 doesn't run on all the newer hardware available today and its latest version, OpenVZ 9 based on RHEL 5.14 kernel, has yet to be publicly released.

When OpenVZ 9 does finally launch, its kernel version will already be outdated, potentially resulting in suboptimal hardware compatibility and performance.

It is true that RedHat backports security fixes, some hardware compatibility and important features from newer kernels, but a 5.14 RHEL kernel certainly isn't exactly the same as a 6.6 (or newer) mainline kernel (and when it is, you still have to wait for such backports).

---

[2019 outdated answer]

First: both projects are awesome and I want both of them to succeed!

---

My personal point of view is that LXC has more vulnerability records, including concerning ones. And, to me, OpenVZ offers a great, easier and more secure experience, including the new OpenVZ 7.

Through the history of documented vulnerabilities from OpenVZ and LXC:

• From the three vulnerabilities found on OpenVZ, even when they were not fixed, they didn't allow privilege escalation or code execution
• From the eight vulnerabilities found on LXC, one documented on 2019 allowed code execution with root privileges on the host machine and other allowed privilege escalation

Some additional points:

• The venet network model of OpenVZ is more secure and more isolated 1
• A container on venet network (OpenVZ) cannot sniff the network traffic of neighboring containers 1

1 https://wiki.openvz.org/Differences_between_venet_and_veth

As stated in this article:

OpenVZ does security via the "bottom up, all included principle". Containers are very solidly isolated against each others. Over the years there have been a few issues and vulnerabilities, but in general you can say that they did a splendid job. Because security was first and foremost on their mind. Not just the container isolation, but also network security. If you allow root access to an untrusted client on one Container, then you don't want him sniffing the network traffic of neighboring Containers, the node or even the whole subnet. For that reason OpenVZ had introduces the "venet" network interfaces, which tackled that in a really neat, orderly and (for the end user) very simple fashion.

Answer 2

One of the most new and most promising security technique specific to LXC is the usage of low-privileged containers, which is possible only thanks to the tight integration of LXC within the Linux kernel. It relies on user's namespaces which allows the users within the LXC to be seen as some kind of "sub-users" from the container owner.

If the container owner is root, as it is required for most containers-like systems, this will not change anything in terms of security (or at least noticeably). However, the "magic" here is that the container can be owned by a unprivileged user, and in this case the container's root user will have the same privilege on the system as the container's owner, ie. the unprivileged user.

A good source of information about all this comes from Stéphane Grabers' blog, one of the developer involved in LXC project.

Answer 3

(Disclaimer: I am not an authority on OpenVZ. This answer is more opinionated than my answers usually are, so feel free to criticise!)

OpenVZ might be "more" secure in that it does not integrate with the entire kernel, so that its attack surface is a bit lower. Though, essentially OpenVZ is what served as inspiration for namespaces and hence ultimately, LXC and Docker. I don't believe it's going to be continued for long now that those more complete solutions are, well, complete.

As pointed out by WhiteWinterWolf one of the big differences is that LXC finally gets to use the user namespace, opening the ability of unprivileged users to run containers and ensuring that contained code that breaks out of the container retains unprivileged users' privileges. Also, namespace-based containers may eventually be fully SELinux-labelled. Docker containers normally already are, and Dan Walsh is working on a way to make SELinux automatically enforce an extra layer of isolation between containers by using randomly generated categories for contained processes.

So in summary, containers are better because: - They can partially thwart some container breakouts (limiting them to an unprivileged UID), making privilege escalations inside the container irrelevant. - They are more supported and more actively developed, and in particular they'll greatly benefit from SELinux support.

And they are worse because: - Their TCB is very large, across the entire kernel and bugs will occur every now and then leading to exploits and breakouts. - The user namespace feels to me to be kind of an edge case. You usually achieve privilege escalation via a bug in the SCI (which you would be able to reproduce after your breakout) or confused deputy attacks on a privileged service (which are likely to keep existing outside your container in the first place). So you would still need to tightly limit that container-running UID to running containers.

In summary, keep practising defence in depth, and keep thinking about how you let contained processes interact with the outside world and how you run containers. Differences exist but as you can see are rather minimal.