Red Hat Enterprise Linux Blog

This is why I'm really hoping RDMA [1] will catch on soon. It would be great if there was a cloud provider that would enable this feature on some of their offerings. Amazon has done something similar by allowing kernel bypass via DPDK [2] with their ENA offering but Kernel bypass is inferior to RDMA in so many ways IMO.

At this point we have 200Gbit/s NICs being provided by Mellanox [3]. CPUs aren't getting any faster and the scale out approach is extremely difficult to get right without going across NUMA domains [4]. Based on the progression of CPUs lately there just isn't going to be enough time to process all these packets AND have time left over to actually run your application. There's a lot of work focusing on data locality at the moment but at this point it's still not fool proof and the work that has been done is woefully under documented.

As the article mentioned we've already added a bunch of hardware offloads. RDMA is just a continuation of these offloads but unfortunately it requires some minor changes on the application side to take advantage of which is why it's probably been slow to be adopted.

RDMA has so many great applications for data-transfer for backend services. Whether it's queries between a web-server and a DB, replication/clustering of DBs, or micro-service fabric with micro seconds latency. Overall there's a lot of low hanging fruit that could be optimized with RDMA.

[1] https://en.wikipedia.org/wiki/Remote_direct_memory_access

[2]…

This exploit is interesting, but if you are doing container security correctly it’s actually not a big deal. In particular if you are setting per-container usernamespaces, like you ought to be, then this exploit doesn’t do anything. In fact you can actively give a usernamespaced container any CAPs you want, because they are isolated to that container’s uid:gid offset.

Obviously, giving containers unecessary CAP privileges in unwise, but if you are practicing sound security best practices then there would be multiple layers of defense between you and this CVE. I think a strong AppArmor profile and SecComp profile would also make this CVE moot.

Edit:
Also, this exploit relies on you being able to fork up to a certain pid value. You can and should take advantage of Linux’s per cgroup ulimit functionality. No container needs more than 255 threads (even if they do you can make special exceptions for such applications).

Edit2:
Additionally this CVE relies on the getuid syscall being available, there is no reason to give a container this syscall, you should block it, ala this guide:
https://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/

I have to say I’m more than a little dissapointed in Twistlock for not pointing out what countermeasures you can employ against this and other CVEs.

Container virtualization in Linux is actually quite old. First appearance in Linux around 2001: http://rhelblog.redhat.com/2015/08/28/the-history-of-containers/
and the concept and real practice realization (in commercial products) of containers is even older. It has roots back to 1979! https://dzone.com/articles/evolution-of-linux-containers-future

Docker is only a philosophy (one application in one container) and toolset around this containers. And docker itself is quite new in comparison.

"This isn't a reason why DBs are a bad fit in itself, but it's a reason why running production data in Docker is a bad idea at present."

You cannot say this in general. As everything in the world this really depends on what you are trying to achieve with your system.

You should at least isolate all your containers from the host machine using a virtual machine.

LXC security can doubtless be mis-configured; how much info can you share regarding your setup? From a few minutes research it sounds like you need user namespaces and seccomp for starters.

Redhat|OpenStack relies on SELinux much more than seccomp: https://news.ycombinator.com/item?id=14220503 http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/

Abusing Privileged and Unprivileged Linux
Containers (2016) | https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaperpdf/

You should get some free testing from your Show HN! https://news.ycombinator.com/item?id=14245447

Despite the plethora of Docker articles here on HN, I haven't paid much attention to containers. Reading this article, I get the impression that they occupy a niche somewhere between a chroot jail and a VM.

The question is, how to deploy an application in this kind of environment? Maybe I build a minimal container and find that a DBMS works fine until it does something like dlopen("/usr/lib/libxml2.so"). Oops, rebuild the container with another library and try again.

After fixing one of the broken links in the blog post, I found this article, which describes an Oracle container:

http://rhelblog.redhat.com/2014/10/29/containerizing-databases-with-red-hat-enterprise-linux/

Yes it will.

Although some of the tuning there-in can be used for improving performance on any workload (handling NUMA, for example), it's probably not necessary for the majority of environments because it involves intimate knowledge of hardware, software and application stack.

It also talks about disabling a bunch of power management which is really only necessary when you're chasing microseconds.

BTW if you're interested in NUMA and memory management on RHEL7, my team mate Bill Gray wrote an awesome whitepaper:

http://rhelblog.redhat.com/2015/01/12/mysteries-of-numa-memory-management-revealed/
(sorry, again login required)

OP: please consider RHEL :-)