←back to thread

441 points longcat | 4 comments | | HN request time: 0.657s | source
Show context
roenxi ◴[] No.45038912[source]
Honest to goodness, I do most of my coding in a VM now. I don't see how the security profile of these things are tolerable.

The level of potential hostility from agents as a malware vector is really off the charts. We're entering an era where they can scan for opportunities worth >$1,000 in hostaged data, crypto keys, passwords, blackmail material or financial records without even knowing what they're looking for when they breach a box.

replies(4): >>45039149 #>>45039756 #>>45043435 #>>45049665 #
fsflover ◴[] No.45039149[source]
> I do most of my coding in a VM now

Perhaps you may be interested in Qubes OS, where you do everything in VMs with a nice UX. My daily driver, can't recommend it enough.

replies(2): >>45039251 #>>45041392 #
mikepurvis ◴[] No.45039251[source]
How does it avoid the sharing headaches that make the ergonomics of snaps so bad?
replies(1): >>45039322 #
1. fsflover ◴[] No.45039322[source]
I never used snaps, so I don't understand what you mean here. Here's a couple of typical Qubes usage patterns: https://www.qubes-os.org/news/2022/10/28/how-to-organize-you..., https://blog.invisiblethings.org/2011/03/13/partitioning-my-...
replies(1): >>45040920 #
2. mikepurvis ◴[] No.45040920[source]
One of the biggest ones is around access to the home directory, ~/.whatever, that kind of thing. Like a browser downloads something, a text editor opens it, it gets run from the terminal and creates a new executable, that new executable is run and mutates something else that the text editor also had open, etc etc. If all the apps have access to ~ then it's https://xkcd.com/1200/ and there's basically no point in the isolation, but if they each have their own ~ then sharing files between apps is a user-hostile headache.

From that article, it looks like perhaps the difference is that snaps are isolated at the app level, whereas qubes is a layer down, where each qube is a kind of workspace with multiple apps potentially installed in it. That seems reasonable enough, though you do have to be willing to pay the disk and mental overhead cost associated with setting up the same tools multiple times, or maintain playbooks/whatever to automate that, or am I going to figure out how to get my one VSCode instance access to the different isolated environments where I need an editor, and if I do that have I basically compromised the whole system model.

replies(2): >>45041467 #>>45041532 #
3. orblivion ◴[] No.45041467[source]
The "Admin" of QubesOS (dom0) is in its own VM, and it doesn't have Internet access. Nothing you download from a browser in another VM can touch dom0 without a VM break. Each VM has its own file system. Even if you wanted to copy a downloaded file to dom0, Qubes makes you jump through hoops to do it.
4. orblivion ◴[] No.45041532[source]
As for setting things up multiple times - you can install stuff in the "Template VM" which is where the OS goes. Every "App VM" mostly just has files in their own ~/. Any changes an App VM makes to its system files won't affect other VMs, or even survive a restart. There are "playbooks" with Salt but I never figured that stuff out. If you pass around some setup scripts instead, that's an attack vector, but I don't think drive-by attacks like the OP would target something sophisticated like that yet.