
CVE-2016-6213 was reported three years ago by OpenVZ developer - ligurio
https://bugzilla.redhat.com/show_bug.cgi?id=1356471#c6
======
mrmondo
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.

~~~
jamescun
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.

~~~
mrmondo
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...

~~~
kolyshkin
> 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.

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

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

~~~
laurencei
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

