Containers or Virtual Machines: Which is More Secure? (zdnet.com) 90
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."
Jails? (Score:4, Informative)
No jails?
Re:Jails? (Score:5, Insightful)
chroot is to security as RAID is to backups.
Re: (Score:2)
You can to backups with RAID though, for example removing a drive from RAID1, and keeping that one as backup. But the RAID is just the tool here, it is not the backup and does not do backups by itself.
In the same way, chroot can be part of a security mechanism, but it does not absolve you from knowing what you are doing. Which is pretty much the real problem with security: Too many people that have no real clue what they are doing with regards to security. Unless that is fixed, software will remain insecure
Re: (Score:2, Interesting)
Jails on ZFS. Nothing better. Unless, of course, you can afford an IBM Z-series mainframe.
Re: (Score:3)
AIX LPARs come to mind as well. In fact, I remember the IBM guys saying that not using PowerVM would have less performance than using a LPAR and two VIO servers (trust me... you want two for redundancy.)
I have never read about a leak out of a LPAR, so IBM did something right.
Do I consider virtualization more secure than containers? If a VM corrupts its own filesystem, you can just toss the VM and rebuild. If a container shits the bed somehow, it can affect the host machine's filesystem, especially if the
mayor container developer says containers are secu (Score:3, Insightful)
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.
Re: (Score:2)
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.
Re: mayor container developer says containers are (Score:4, Insightful)
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.
Re: (Score:2)
Yeah, what does IBM know about VMs? They've only had VM products for about 50 years.
Re: Solaris zones? (Score:2, Funny)
Because this article is talking about things people use
Re: (Score:2)
Because most people dumped Solaris more than a decade ago?
Re: (Score:1)
Not entirely. I still run across the odd solaris 7/8/9 system from time to time. I still run one myself. You don't fuck with what isn't broken; there hasn't been a need to replace it, although it has been discussed. (maybe should based entirely on the power bill)
(I have several systems standing by for testing and troubleshooting whatever might come across my desk. But they aren't actually on.)
Re: (Score:1)
Not entirely.
Not entirely what? Re-read my post. I didn't say everyone dumped Solaris, but Solaris was relegated to niche status by most people long ago. There's a good reason Sun made OpenSolaris 13 years ago and it wasn't because they had tons of paying customers.
Re: (Score:1)
"Not entirely" as in [in my experience] many former solaris shops still have bits of solaris remaining. It wasn't "dumped", but incrementally replaced over the years. (solaris 10 was the real kick-in-the-ass to start moving... SMF, the systemD of the Solaris world.)
OpenSolaris was as much a marketing ploy as it was a means to remain relevant -- "Open Source" being the trendy new buzz word / business model. You could already get solaris for free -- fo
Re: (Score:2)
Or how about a virtual machine hypervisor running within a Solaris zone? Because this is what SmartOS does for its hypervisor.
"container with a well crafted seccomp profile" (Score:5, Insightful)
"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.
Re:"container with a well crafted seccomp profile" (Score:5, Insightful)
VMs and Containers (e.g. Docker) are exactly as secure as the software you install inside of them.
Most developers who like containers like them because they don't have to use the OS versions of Apache or whatever and aren't stuck dealing with the sysadmin constantly breaking things with his security updates.
The containers these developers build tend to be woefully insecure.
Re: (Score:3)
That cuts both ways, though: one useful thing about containers is that I can test new versions and security updates in relative safety on a separate container that is otherwise identical to production, prior to updating my main production containers.
Re: (Score:3)
The same can be done with VM's and automation. I do that now by spinning up a new VM with all the updates I want to test and then using automation tools (in my case, saltstack) to set it up exactly the same as my production VM (with any additional changes, if necessary). It takes a bunch of initial work in configuring the automation but once its there, its pretty easy to maintain.
Quite often when there's a lot of changes, rather then updating the production VM's, I'll just set up all new ones (via the sam
Re: (Score:3)
Indeed. Those system administrators are failures too, all but begging for hackers to get a toehold inside their main security perimeter.
This. I'll have real-world data next month (Score:5, Interesting)
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)
Re: This. I'll have real-world data next month (Score:2)
Only thing I've ever really used chroot for is installing Funtoo linux via SystemRescueCD.
Anyone who thinks it's meant for security needs a smack upside the head.
Try it. You can. Copy-paste. Same code as cd (Score:3)
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.
Re: "container with a well crafted seccomp profile (Score:2)
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
Re: (Score:2)
Your security always depends on something being "well crafted", namely your application software. Everything else is just fools trying to patch their bad software engineering in ways that do not really work.
Answer (Score:5, Insightful)
Re: (Score:2)
Not break. Steal data from an adjacent one? Yes. And even then it's a bit of a crapshoot as to what you get, not at all the same as busting in and taking what you want.
Re: (Score:1)
Bad Editing Again ... (Score:1)
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.
Containers by definition are not more secure... (Score:4, Insightful)
Re: (Score:1)
A vm should be more secure since they have to use CPU-level features to provide protection. A container trusts software more than hardware, so of course they're less secure.
Re: (Score:2)
Unless said CPU-level features have bugs themselves. Like, I don't know, Specter? A kernel running containers may well mitigate that, but a VM layer may negate that mitigation again.
Re: Containers by definition are not more secure.. (Score:2)
Re: (Score:2)
Not necessarily and very much not "by definition". You overlook KISS here. VMs are complex and offer a nice, large attack surface all by themselves. A container can very well be more secure, for example if the hypervisor creates attack vectors not present in a container running on a proper, non-virtualized system.
Now, I am not saying this is always the case or even regularly. But the question does not have a simple answer.
Re: Containers by definition are not more secure.. (Score:2)
Re: (Score:2)
Security, at least when done above amateur-level, is not black and white.
None (Score:3)
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 [wikipedia.org] 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 [cam.ac.uk] project.
The other day, I stumbled over the CloudABI [cloudabi.org] 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.
Re: (Score:2)
Indeed. And on the other hand, write better software. There is a lot of things sandboxes cannot do, for example protecting the data the application works with. So use proper privilege separation and drop, use input validation, etc. and make very sure you understand what you are doing. Especially the last thing is the one thing that really helps and that is missing so often these days.
The problem of VMs, (Score:2)
Re: (Score:2)
BusyBox doesn't exactly add a lot of bloat. Stop running a full OS in your VMs.
Theory (Score:2)
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.
Re: (Score:2)
Bug density is a somewhat useless metric for software quality. When it comes to security, it is utterly meaningless.
VM's and VLAN's (Score:2)
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.
Re: (Score:2)
VLANs are not a security technology. They make managing a network easier, but as soon as you compromise one network device, you have access to everything. Proper isolation means different cables.
Containers have come a long way since chroot... (Score:2)
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
Neither. Wrong tech. (Score:2)
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 contai