Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unfashionably secure: why we use isolated VMs

blog.thinkst.com

Post reply on HN
Print view View original

71–80 of 256 posts

Re: Unfashionably secure: why we use isolated VMs

#71

Post by tptacek »

Veserv wrote: post #33
fsckboy wrote: post #22

just as a meta idea, i'm mystified that systems folks find it impossible to create protected mode operating systems that are protected, and then we all engage in wasteful kluges like VMs. i'm not anti-VM, they're great technology, i just don't think it should be the only way to get protection. VMs are incredibly inefficient... what's that you say, they're not? ok, then why aren't they integrated into protected mode O…

[flagged]

This Theo quote from 18 years ago gets brought up a lot. It's referring to a different era in virtualization (it practically predates KVM, and certainly widespread use of KVM). You can more or less assume he's talking about running things under VMWare.

In the interim:

* The Linux virtualization interface has been standardized --- everything uses the same small KVM interface

* Security research matured and, in particular, mobile device jailbreaking have made the LPE attack surface relevant, so people have audited and fuzzed the living hell out of KVM

* Maximalist C/C++ hypervisors have been replaced by lightweight virtualization, which codebases are generally written in memory-safe Rust.

At the very least, the "nearly full kernel" thing is totally false now; that "extra" kernel (the userland hypervisor) is now probably the most trustworthy component in the whole system.

I would be surprised if even Theo stuck up for that argument today, but if he did, I think he'd probably get rinsed.

Re: Unfashionably secure: why we use isolated VMs

#72

Post by fsflover »

Veserv wrote: post #33
fsckboy wrote: post #22

just as a meta idea, i'm mystified that systems folks find it impossible to create protected mode operating systems that are protected, and then we all engage in wasteful kluges like VMs. i'm not anti-VM, they're great technology, i just don't think it should be the only way to get protection. VMs are incredibly inefficient... what's that you say, they're not? ok, then why aren't they integrated into protected mode O…

[flagged]

Show me a recent escape from VT-d and then you will have a point.

Re: Unfashionably secure: why we use isolated VMs

#73

Post by tptacek »

mwcampbell wrote: post #64
tptacek wrote: post #59

The cool kids have been combining containers and hardware virtualization for something like 10 years now (back to QEMU-Lite and kvmtool). Don't use containers if the abstraction gets in your way, of course, but if they work for you --- as a mechanism for packaging and shipping software and coordinating deployments --- there's no reason you need to roll all the way back to individually managed EC2 instances. A short s…

Since you're here, I was just thinking about how feasible it would be to run a microVM-per-tenant setup like this on Fly. I guess it would require some automation to create a Fly app for each customer. Is this something you all have thought about?

Extraordinarily easy. It's a design goal of the system. I don't want to crud up the thread; this whole "container vs. VM vs. dedicated hardware" debate is dear to my heart. But feel free to drop me a line if you're interested in our take on it.

Re: Unfashionably secure: why we use isolated VMs

#74

Post by Gud »

gryfft wrote: post #7
PedroBatista wrote: post #2

As a permanent "out of style" curmudgeon in the last ~15 years, I like that people are discovering that maybe VMs are in fact the best approach for a lot of workloads and the LXC cottage industry and Docker industrial complex that developed around solving problems created by themselves or solved decades ago might need to take a hike. Modern "containers" were invented to make things more reproducible ( check ) and sim…

I've been meaning to do a bhyve deep dive for years, my gut feelings being much the same as yours. Would appreciate any recommended reading.

Read the fine manual and handbook.

Re: Unfashionably secure: why we use isolated VMs

#75

Post by ploxiln »

> we operate in networks where outbound MQTT and HTTPS is simply not allowed (which is why we rely on encrypted DNS traffic for device-to-Console communication)

HTTPS is not allowed (locked down for security!), so communication is smuggled over DNS? uhh ... I suspect that a lot of what the customer "security" departments do, doesn't really make sense ...

Re: Unfashionably secure: why we use isolated VMs

#76

Post by tomjen3 »

PedroBatista wrote: post #2

As a permanent "out of style" curmudgeon in the last ~15 years, I like that people are discovering that maybe VMs are in fact the best approach for a lot of workloads and the LXC cottage industry and Docker industrial complex that developed around solving problems created by themselves or solved decades ago might need to take a hike. Modern "containers" were invented to make things more reproducible ( check ) and sim…

If anything Docker is underused. You should have a very good reason to make a deploy that is not Docker, or (if you really need the extra security) a VM that runs one thing only (and so is essentially a more resource requiring Docker).

If you don’t, then it becomes much harder to answer the question of what exactly is deployed on a given server and what it takes to bring it up again if it goes down hard. If you but everything in Docker files, then the answer is whatever is set in the latest docker-compose file.

Re: Unfashionably secure: why we use isolated VMs

#77

Post by leononame »

jmnicolas wrote: post #19
01HNNWZ0MV43FF wrote: post #11

Earlier quoted context omitted.

My bank doesn't even have 2FA

Mine neither and they use a 6 numbers pincode! This is ridiculous, in comparison my home wifi password is 60+ random chars long.

But they do ask you only two digits of the pin on each try and they probably will lock your account after three incorrect attempts. Not saying 6 digits is secure, but it's better than everyone using "password" if they have a string policy on incorrect attempts.

And don't hm they have 2FA for executing transactions?

I'm pretty sure banks are some of the most targeted IT systems. I don't trust them blindly, but when it comes to online security, I trust that they built a system that's reasonably well secured and other cases, I'd get my money back, similar to credit cards.

Re: Unfashionably secure: why we use isolated VMs

#78

Post by tetha »

smitty1e wrote: post #49

> Switching to another provider would be non-trivial, and I don’t see the VM as a real benefit in this regard. The barrier to switching is still incredibly high. This point is made in the context of VM bits, but that switching cost could (in theory, haven't done it myself) be mitigated using, e.g. Terraform. The brace-for-shock barrier at the enterprise level is going to be exfiltrating all of that valuable data. Bez…

Heh. We're in the process of moving a service for a few of our larger customers over due to some variety of emergencies, let's keep it at that.

It took us 2-3 days of hustling to get the stuff running and production ready and providing the right answers. This is the "Terraform and Ansible-Stuff" stage of a real failover. In a full infrastructure failover, I'd expect it to take us 1-2 very long days to get 80% running and then up to a week to be fully back on track and another week of shaking out strange issues. And then a week or two of low-availability from the ops-team.

However, for 3 large customers using that product, cybersecurity and compliance said no. They said no about 5-6 weeks ago and project to have an answer somewhere within the next 1-2 months. Until then, the amount of workarounds and frustration growing around it is rather scary. I hope I can contain it to some places in which there is no permanent damage for the infrastructure.

Tech isn't necessarily the hardest thing in some spaces.

Re: Unfashionably secure: why we use isolated VMs

#79

Post by stacktrust »

SunlitCat wrote: post #66
stacktrust wrote: post #48

Earlier quoted context omitted.

HP business PCs ship with SureClick based on OSS uXen, https://news.ycombinator.com/item?id=41071884

Thank you for sharing, didn't know that one!

It's from the original Xen team. Subsequently cloned by MS as MDAG (Defender Application Guard).

Re: Unfashionably secure: why we use isolated VMs

#80

Post by ploxiln »

fsckboy wrote: post #22

just as a meta idea, i'm mystified that systems folks find it impossible to create protected mode operating systems that are protected, and then we all engage in wasteful kluges like VMs. i'm not anti-VM, they're great technology, i just don't think it should be the only way to get protection. VMs are incredibly inefficient... what's that you say, they're not? ok, then why aren't they integrated into protected mode O…

The industry tends to do this everywhere: we have a system to contain things, we made a mess of it, now we want to contain separate instances of the systems.

For example, in AWS or GCP, you can isolate stuff for different environments or teams with security groups and IAM policies. You can separate them with separate VPCs that can't talk to each other. In GCP you can separate them with "projects". But soon that's not enough, companies want separate AWS accounts for separate teams or environments, and they need to be grouped under a parent org account, and you can have policies that grant ability to assume roles cross-account ... then you need separate associated groups of AWS accounts for separate divisions!

It really never ends, companies will always want to take whatever nested mess they have, and instead of cleaning it up, just nest it one level further. That's why we'll be running wasm in separate processes in separate containers in separate VMs on many-core servers (probably managed with another level of virtualization, but who can tell).

Post reply on HN