Hacker News Reader

Comment by OJFord | Hacker News Reader

Unless you use a different VM for everything, you've just moved the problem from 'secure your workstation' to 'secure your VM'.

View on HN

As long as the container isn't leaky, the benefit there is that it makes recovery, back-ups, and isolation easier. For example, dev VM isn't where you would have your creds for bank, SSH keys, etc. So isolation of (more) sensitive, daily-use data is easier. Snapshots of VM are cleaner and fast to rollback, etc. The OP was looking for reasonable mitigations that don't make daily usage a complete drag. I think VMs or other containers fit some of that bill.

But then you still have to draw a line somewhere for what's trusted outside of it - browser & password manager for your bank example, and for SSH keys probably at least some project related tooling that you have to decide to trust or audit or whatever.

If you use both host & VM I think my point stands, the host may as well be another VM (or the VM another physical machine) it's not that it's virtual that's adding anything, it's the separation, which was my point.

> Unless you use a different VM for everything

Why yes, that's exactly the idea.

It's an idea, I didn't think it sounded like the commenter I replied to's idea.

Even one vm with your dev env will isolate your personal and production credentials from the dev environment.

if the thread was npm malware, having your dev instance inside the VM would reduce the fall out. Your personal & prod creds would be outside the VM.

It still goes a long way to reduce fallout with minimal effort & discipline.

You’re right it’s not perfect security, VM still needs securing – but it’s a good ROI

Reply on news.ycombinator.com