6

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.

  • 1
    You say "Using LXC or similar is not an option since my server has a low-performance CPU.", LXC has a very low CPU overhead, maybe you meant that hardware virtualization is not an option instead? – WhiteWinterWolf Jan 31 '15 at 13:36
  • Oh, that was a typo. Wanted to say KVM. fixed it. Thanks for telling me. – Daniel Alder Jan 31 '15 at 13:44
0

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:

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.

  • 1
    Additional point: a root user in lxc without uidmap is the same as the root on the host, which brings a lot of problems on devices, syscalls, mounts... – Daniel Alder Oct 30 at 13:35
  • 1
    Awesome. I like the way how you compared the two, including references, that it's not too much flavoured by your opinion, and that it still results in a very compact answer ;). Too bad I lost track about openvz after support in ubuntu and debian was discontinued due to lxc. And today, (from a usage perspective) docker superseeds lxc in many use-cases (with the same poor security-level as lxc though..) – Daniel Alder Oct 30 at 13:36
  • Thanks for your comment! I am trying to get closer to the OpenVZ maintainers and, in an uncertain future, maybe contribute with something. One item that is in my "todo" list is to create a NodeJS library that integrates the OpenVZ's C SDK, to enable the development of new control panels to manage OpenVZ servers on a modern stack. – Paulo Coghi - Reinstate Monica Oct 30 at 15:30
  • I have the same technical perspective as you, about Docker and LXC. Despite the fact that Docker has matured a lot on its features, it inherits LXC's vulnerabilities, as stated in many places, like techbeacon.com/enterprise-it/… – Paulo Coghi - Reinstate Monica Oct 30 at 15:33
2

(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.

1

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.

  • 1
    Thanks for this interesting link. I took the time to look over it. Unprivileged containers are definitively a must for my system. What scares me are things which I don't think about. For example, I realized yesterday that calling dmesg in a container shows messages of the host. The same thing in OpenVZ returns an empty log in a guest container. The solution btw. is setting kernel.dmesg_restrict=1 or even seccomp – Daniel Alder Feb 2 '15 at 21:02
  • 1
    I can't get it working. I know that's OT here, but what's the best distro and release to try userns? I already tried Debian wheezy, Debian jessie, Ubuntu trusty and Ubuntu vivid, all of them with different errors. – Daniel Alder May 3 '15 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.