Comment by roenxi
3 months ago
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.
Similar, but in a podman container which shares nothing other than the source code directory with my host machine.
I do too, but I found it non-trivial to actually secure the podman container. I described my approach here [1]. I'm very interested to hear your approach. Any specific podman flags or do you use another tool like toolbx/distrobox?
[1]: https://evertheylen.eu/p/probox-intro/
Very interesting. I learned some new things. I didn't know about `--userns` or the flexible "bind everything" network approach!
Here's my script:
https://codeberg.org/chrisdavies/dotfiles/src/branch/main/sr...
What I do is look for a `.podman` folder, and if it exists, I use the `env` file there to explicitly bind certain ports. That does mean I have to rebuild the container if I need to add a port, so I usually bind 2 ports, and that's generally good enough for my needs.
I don't do any ssh in the container at all. I do that from the host.
The nice thing about the `.podman` folder thing is that I can be anywhere in a subfolder, type `gg pod`, and it drops me into my container (at whatever path I last accessed within the container).
No idea how secure my setup is, but I figure it's probably better than just running things unfettered on my dev box.
1 reply →
I would love if some experts could comment on the security profile of this. It sounds like it should be fine, but there are so many gotchas with everything that I use full VMs for development.
One immediate stumbling block- the IDE would be running in my host, which has access to everything. A malicious IDE plugin is a too real potential vector.
I actually run code-server (derivative of VSCode) inside the container! But I agree that there can be many gotchas, which is why I try to collect as much feedback as possible.
I run the ide (neovim) in the container along with npm, cargo, my dev / test databases, etc. It’s a complete environment (for me).
> 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.
Yeah I use Qubes for my "serious" computing these days. It comes with performance headaches, though my laptop isn't the best.
I wonder about something like https://secureblue.dev/ though. I'm not comfortable with Fedora and last I heard it wasn't out of Beta or whatever yet. But it uses containers rather than VMs. I'm not a targeted person so I may be happy to have "good enough" security for some performance back.
secureblue creator here :)
some corrections:
> last I heard it wasn't out of Beta or whatever yet
It is
> But it uses containers rather than VMs
It doesn't use plain containers for app isolation. We ship the OS itself as a bootable container (https://github.com/bootc-dev/bootc). That doesn't mean we use or recommend using containers for application isolation. Container support is actually disabled by default via our selinux policy restricting userns usage (this can be toggled though, of course). Containers on their own don't provide sandboxing. The syscall filtering for them is extremely weak. Flatpak (which sandboxes via bubblewrap: https://github.com/containers/bubblewrap) can be configured to be reasonably good, but we still encourage the use of VMs if needed. We provide one-click tooling for easily installing virt-manager (https://en.wikipedia.org/wiki/Virt-manager) if desired.
In short though, secureblue and Qubes aren't really analogous. We have different goals and target use cases. There is even an open issue on Qubes to add a template to use secureblue as a guest: https://github.com/QubesOS/qubes-issues/issues/9755
1 reply →
How does it avoid the sharing headaches that make the ergonomics of snaps so bad?
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-...
3 replies →
Part of the problem is the traditional PC security model (Linux / Windows). "All the executable files I run are trusted and have access to all my personal files" doesn't work anymore in 2025. Android fixed this for the most part, but on PC SELinux is all we have and it's painful to use.
Exactly this, with note that due ecosystem and history of software, setting up such environment is either really hard or relatively expensive