Slashdot Mirror
Containers or Virtual Machines: Which is More Secure? (zdnet.com)
Are virtual machines (VM) more secure than containers? You may think you know the answer, but IBM Research has found containers can be as secure, or more secure, than VMs. From a report: James Bottomley, an IBM Research Distinguished Engineer and top Linux kernel developer, writes: "One of the biggest problems with the current debate about Container vs Hypervisor security is that no-one has actually developed a way of measuring security, so the debate is all in qualitative terms (hypervisors 'feel' more secure than containers because of the interface breadth) but no-one actually has done a quantitative comparison." To meet this need, Bottomley created Horizontal Attack Profile (HAP), designed to describe system security in a way that it can be objectively measured. Bottomley has discovered that "a Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."
No jails?
should we be surprised?
Btw almost no one maintains good seccomp profiles, it is too cumbersome.
VMs give you better out of the box security than out of the box containers, and he probably knows it.
Why not put that as an option? ;-)
"a Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."
Hypervisor it is, then!
Seriously - if your security depends on something being "well crafted", you might as well have no security - because eventually, it won't be "well crafted" - somebody will screw it up.
Answer: Neither. Intels CPU bugs have made it possible to break both.
All running inside a universe in a universe.
Where exactly does it say, "or more secure" Mr. Editor?
Not knocking article itself arguing the potential gains in container security possibly on-par with virtualization, but the extra crap step of modern Slashdot editors.
than virtual machines. Why is this even a question?
That's why I always run my containers in VMs!
i'd be interested in knowing whether or not there is spy ware in the hardware but with things like contiki you can still push old tech quite far.
with new tech all i hear is crying about back doors, privacy/security issues, what have you.
old apple computers function great, they may need a little getting used to but they are solid. i've yet to encounter some type of segfault, hard lock, or other type of failure. data on old floppy disks remain intact like a precious diamond for years and years, unlike the crappy quality from the PC/MSDOS days.
other than possible TEMPEST attacks, i'd like to read anything from a researcher proving other attacks (and in addition, comparable to modern systems) against old apple computers.
I don't mean Macs. No OSX, nothing, I mean old Apple computers like Apple ][e.
Previously on /.:
Contiki for Internet-enabled Apple II
Youâ(TM)re right with the why is this even a question part. Of course a real vm is more secure than a container.
Beyond a deployment convenience, I mean.
Is it a container/vmware device you build where you know everything or one a vendor provides that says its secure.
Btw almost no one maintains good seccomp profiles, it is too cumbersome.
VMs give you better out of the box security than out of the box containers, and he probably knows it.
More to the point, a container running on a VM is quite obviously less secure than directly running on the VM. If you're running on someone else's hardware (cloud etc), then your choices are VM or container-in-a-VM, so that's pretty obvious. If you're running on your own hardware, then it's a pretty odd security concern to be very worried about either breach.
Socialism: a lie told by totalitarians and believed by fools.
Yeah, what does IBM know about VMs? They've only had VM products for about 50 years.
Exactly. An ideal container, perfectly configured and perfectly implemented, with a more-secure but less- convenient settings, would be -
Well it would be non-existent, because shit ain't perfect. If things in the real world were perfect, security wouldn't be much of an issue.
I'll have hard data in real-world containers and VMs next month. My company (Alert Logic) just released a suite of security services for containers so we will be able to tell exactly how often, and in which ways, our customers actual containers are breached, and what vulnerabilities they actually have. I can cross-reference that data with VMs in my database.
Based on decades of experience, I expect the data will show that VMs are more secure. I also expect the data will show that what you put IN the container or VM is far more important than whether you put it in a VM or container. Stupid in a VM is stupid, stupid in a container is stupid. Containers can use less RAM, though.
Someone mentioned chroot, which is the basic system call behind containers. Chroot is not a security tool. Chroot was not designed for security. Chroot does not provide security of any kind. Leaving chroot is as simple as chrooting again:
mkdir foo; chroot foo; cd ..
Chroot is useful for cross-compiling and certain other tasks related to developing software. It was created for the purpose of compiling and testing BSD4.2 before it was ready for release. Bill's machine ran 4.1, he could switch to 4.2 versions of the files by running chroot. (And could go back to the 4.1 system by simply running chroot again)
Systems such as containers, pledge, seccomp, jails, systrace variants, chroot etc. are all about restricting what otherwise would have been a process's ambient authority by plugging holes here and there until you can't find any more holes to plug. The problem is the holes that you don't find.
Another approach is to do the opposite: start with the process having no authority and give it only explicit access to the specific interfaces of the specific objects it needs to do its job --- and nothing more.
That is called Capability-based security and is IMHO the only fail-safe way to sandbox processes.
Some of Unix's predecessors had capabilities, some even with special CPU support so that it did not hav emore overhead than shifting pointers, but it was one of those many things that were not included when the original Unix was written to work on off-the-shelf hardware.
In recent years, a capabilities model has been added to BSDs and Linux in the form of the Capsicum project.
The other day, I stumbled over the CloudABI system, which is a runtime environment that uses Capsicum for applications on cloud servers.
With CloudABI your applications would be sandboxed just as safely as if they ran on virtual machines but without the overhead.
The big drawback is that programs need to be rewritten for it. The idea is though that when rewriting a program for CloudABI you should mostly just have to change things to make it compile and run. This would entail quite a bit of gruntwork but it should be pretty much straightforward and therefore less error-prone than to tweak security policies for something like seccomp or SELinux.
And BTW, chroot was never intended to be used for sandboxing.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
is that they are HUGE, ..! A big maintenance effort, more lingering bugs, bigger attach surface, plenty of possibilities to hide nasty things. Containers are a much smaller thing to take a look in and review, keep updated etc.
There are working examples for both containers and VMs for some of the biggest security issues to date. You're fucked with either.
I recommend you use dedicated hardware and minimize the number of services you install on said hardware. Isolate equipment through standard practices in networking.
The notion of self-secure system stinks of utopia. First of all, security of complex system is not a static state it's a dynamic state of an eternal sword and shield fight
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
The approach described is pure theory, with bold assumptions such as uniform bug density. I am not sure the model can predict anything, and I am not even sure it fits existing experimental data.
It is almost as useless as dark matter in cosmological models.
Surprised nobody has made this point yet.
A VM can be set to run as a part of a VLAN, giving you a little extra bit of security.
Pretty much. Containers still rely on the underlying software and hardware to not be bad. VMâ(TM)s donâ(TM)t isolate everything unless you are only using the hyper visor to partition a single machine. As soon as network fabric is involved itâ(TM)s not any more secure than physical blades in a blade enclosure.
VLANs are just suggestions, which can be ignored if any traffic from other VLANs are on the same wire.
VLANs don't provide security. They provide logical separation "suggestions" which can be ignored.
but still, are lacking in the security department.
VMs in theory should be more secure, but in practice, Hypervisors are such huge behemoths that there are always security holes in the hypervisor.
In reality, discussing the relative security between containers and VMs is like discussing how many angels can dance in the head of a pin, a futile excersice.
the relative security will ebb and flow, some times in favour of VMs, sometimes in favour of Containers.
But in the end, it will not matter, as we all will end up running our containers inside VMs, sacrificing some of the performance gains of containers for the HUUUGE sysadmin advantages of VMs.
*** Suerte a todos y Feliz dia!
If you're running on your own hardware, then it's a pretty odd security concern to be very worried about either breach.
"If you're running on your own hardware, then it's a pretty odd security concern to be very worried about either breach."
Not quite so. In practice, you might want to run a subset of your applications and sensitive data in the VM. Each of your VMs might have a special purpose, each requiring only a subset of your data.
You're worried that hackers can get to one VM, but it's important that the other VM is super-secure, yet you don't run them on different hardware? Pretty odd.
Socialism: a lie told by totalitarians and believed by fools.
Is that what you think about? You are probably gay. You lash out at people because you are old and befuddled and too slow to do any computer work today. Sad, really.
Containers and VMs are not really security tech. Nobody in their right mind would call using a dedicated machine a "security technology", VMs and Containers are not either. They serve to partition a machine and, to a limited degree, they can achieve that. But as soon as somebody breaks into a container or a VM, they can usually do what they want anyways, just the same as with a dedicated system: Send spam, hack other machines using the identity of the container of VM, steal local data, etc.
What both containers and VMs give you is _less_ security compared to a dedicated machine, since in addition to all the normal security problems, you also get possible attacks on the isolation layer and on other containers or VMs running on the same hardware. That means overall, you are _less_ secure.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Also, unless there are bugs in the software using the hardware, which there is
"First they came for the slanderers and i said nothing."
I will argue that in this case, there is a simple answer: both are insecure.
"First they came for the slanderers and i said nothing."
Security, at least when done above amateur-level, is not black and white.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Are people really so stupid to fall for all these promises and shiny infographics of individual containerization systems? Are people aware that systemd is not just a sysv init replacement, and that it exposes all the kernel's namespacing and containerization features through its simple API? Why would you need dockers, rockers, nablas, kuberneshits, ..., and a dog, when you can achieve all that, seccomp filtering included, with a service unit file? You can even use it with your own ostree if you really need that, via (among other options) RootDirectory option.
CHROOT is also useful for running older software on newer systems.
My Linux box died some years back. As in physically died. The motherboard failed. I replaced it, only to find my ancient 10+ year old Linux kernel couldn't handle the newest hardware. So I updated Linux. But then I had some problems migrating my MySQL (yes this was back before Sun sold to Oracle) data over to the updated version.
So, boot of RedHat rescue image off the CD. Use dd to make a copy the old Linux partition onto a new drive. Mount. CHROOT to the copy of the ancient Linux boot partition. Now I could manually start the ancient version of mysqld from /etc/init.d under the latest kernel. And then export my data out.
CHROOT was a lifesaver. So say nothing of backward compatibility in Linux on a scale that dwarfs the imagination.
Try it. Copy and paste the commands. If you look, especially at old systems, you'll notice the code for chroot looks an awful lot like the code for cd. There's a reason for that.
Cd changes which directory the "." alias points to, chroot changes which directory the "/" points to. Just as you can cd to change ".", then cd again to change it again, chroot works the same way. It's just about as "secure" as cd, because it's almost the same code.
We have a customer has a requirement for redundant servers. So he's going to run two in two vms in the same box. Great. Same cabling, same power supply, same cpu, same disk drives (probably) same memory. Wonderful.
Paravirtualization is faster and smoother than virtualization.
Properly implemented VLANs can act as a course-grained ACL. The only valid VLANs on a port is whatever the port is tagged with. It's not like traffic on any port can just tag a frame as the management VLAN and gain access.