CVE-2016-6213 was reported three years ago by OpenVZ developer | Hacker News Reader

CVE-2016-6213 was reported three years ago by OpenVZ developer

bugzilla.redhat.com

43 pointsligurio14 comments

Interesting, my 2c: You shouldn't be using OpenVZ in 2016 regardless, I know lots of budget web hosting providers still provide it as an option but really IMO they should have moved on around 2-3 years ago.

why not?

May I ask why not?

I feel OpenVZ gets a bad rap simply because of the "pop up" VPS providers who oversell and under-provision. It is a mature, maintained containerisation system. Yes it still requires kernel patches (created before Linux had namespaces/cgroups etc) but the team is actively working on merging missing functionality upstream and adapting OpenVZ tools to support things like namespaces and cgroups.

This. I've used OpenVZ for internal containerisation (before the whole Docker explosion) without any issues. It's fast and provides what feels like a fully blown virtual machine. Yes, it's a bit out of date these days (being on Linux 2.6), but it's still an incredibly useful tool, and I see no reason to stop using it.

Kernel 2.6 is more than a bit out of date, ok maybe kernel 3.18 is a bit out of date but kernel 2.x (and really 3.x) is /really/ out of date.

Actually, OpenVZ based on RHEL7 (3.10+) kernel is available. https://lists.openvz.org/pipermail/announce/2016-July/000664...

Again, please, don't judge kernel by its version number. The kernel that RHEL6 comes with has version of 2.6.32, but it's as far from "vanilla" 2.6.32 as Chicago from Seattle. It has tons of patches (with OpenVZ patchet being only about 10% of it). There's a somewhat old comparison about RHEL5 patch set that you can see here: http://openvz.livejournal.com/27592.html

Well for starters I believe it still relies on Kernel 2.6, I think they forked the kernel then never kept it up to date, I could be wrong about this but it certainly was the case up until recently at least. Looking at OpenVZ's website it also seems to only official support RHEL 5/6 as stable host options which were behind their time at point of release and now in 2016 really are very, _very_ old dogs.

LXC and Docker, especially when combined with a virtualisation layer and SELinux are modern, stable, well maintained options that are not only easy to configure and manage but do not require custom kernel patches etc...

> I believe it still relies on Kernel 2.6, I think > they forked the kernel then never kept it up to date

Sad to see you spreading FUD without knowing much. Let me describe how it's really working.

OpenVZ kernels are based on RHEL (Red Hat Enterprise Linux) kernels. Yesterday we have released OpenVZ 7 which is based on RHEL7 kernel, which is loosely based on 3.10 (I hear you say "old kernel!" -- more on that below).

OpenVZ kernel developers are doing two things: 1. merge our patches upstream; 2. port our patches to a newer RHEL kernels.

As for merging our patches upstream, it's usually happens by rewriting pieces from scratch, and therefore the process is slower than we'd like. So far we have succeeded in having PID and network namespaces, some cgroup controllers, and CRIU (checkpoint/restore, a prereq to live migration -- it's mostly in userspace but there are about 170 kernel patches). I estimate this makes us (Virtuozzo/OpenVZ team) the biggest contributor to the containers in the Linux kernel. This contribution of ours enables technologies such as Docker, LXC etc. In other words, we made Docker and LXC possible.

As for porting our kernels, yes, we use RHEL kernels as a base for ours, as we believe that Red Hat is doing great work keeping their kernels stable and secure. What they do is fork a kernel (2.6.9 for RHEL4, 2.6.18 for RHEL5, 2.6.32 for RHEL6, 3.10 for RHEL7) about a year or so before a RHEL x.0 release, and then they maintain that fork, fixing bugs and improving stability, and sometimes porting new features, but [almost] not introducing new bugs. We value this work, and we use it as a base. So, yes, the latest and greatest RHEL7, and the latest and greatest OpenVZ 7 are based on somewhat rusty 3.10 kernel. Having said that, 3.10 is just a version number of the kernel that was used, a few years back, as a base for the RHEL kernel. It's been heavily patched since that time, but still bears this 3.10 number.

Hope that makes it more clear. Please spread the truth.

> modern, stable, well maintained options

See, we do OpenVZ kernel releases on an almost weekly basis. But since it's 2.6.32, or 3.10, it makes us unmodern, unstable, and not well maintained, right? Wrong.

Really? OpenVZ still has some advantages to compare with other virtualization solutions https://openvz.org/Comparison

Thats not even close to up to date and is incorrect.

They're only just moving from their 2009 Kernel fork to a fork of Kernel 3.10 which was released in 2013...

Edit: In fact, on second inspection, a lot of the items in that table are either wrong or straight out lies (although I'm assuming the former). I'd hate to think what the community around the product is like but I can only assume they live in a bubble similar to those in the Drupal community that thinks for whatever reason that the product they're using is the one and only / best solution rather than truly evaluating the best tool for the job, as far as I can see it unless that page you linked to truly isn't maintained thats the only way you could end up with that quality of information / misinformation available.

Edit2: Formatting

It was actually two years ago, if someone wants to correct the title.

Edit: I clearly can't read. Upvoted you both, thanks.

No - the comment text says "I've reported this problem two years ago" - but the date of the report is 20th Jun 2013 - which is definitely 3 years ago

The email was sent in June 2013, three years ago. The author mistyped the year in his comment on the bug report.

Reply on news.ycombinator.com