4 ms·

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 fr

by roenxi 1y 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.

fsflover 1y ago
> 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.
- mikepurvis 1y ago
  How does it avoid the sharing headaches that make the ergonomics of snaps so bad?
  - fsflover 1y ago
    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-your-qubes/ https://www.qubes-os.org/news/2022/10/28/how-to-organize-you..., https://blog.invisiblethings.org/2011/03/13/partitioning-my-digital-life-into.html https://blog.invisiblethings.org/2011/03/13/partitioning-my-...
    - mikepurvis 1y ago
      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/ 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.
      - orblivion 1y ago
        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.
      - orblivion 1y ago
        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.
- orblivion 1y ago
  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/ 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 1y ago
    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 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 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 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 https://github.com/QubesOS/qubes-issues/issues/9755
    - orblivion 1y ago
      I keep hearing different things about how well containers can isolate. I guess the "on their own" caveat is the important one. I don't really know how they work. Hearing not to rely on it from the developer of secureblue is pretty strong case. Thanks.
christophilus 1y ago
Similar, but in a podman container which shares nothing other than the source code directory with my host machine.
- evertheylen 1y ago
  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/ https://evertheylen.eu/p/probox-intro/
  - christophilus 1y ago
    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/src/pod/pod.sh 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.
    - evertheylen 1y ago
      Yeah props to the `pasta` tool, it solves a specific problem really well. Nice script! I considered a similar approach that's based on "magic" files in the filesystem before, but it was difficult to get the security right. In your case I believe a malicious script can just overwrite .podman/env and it will be sourced by the host the next time you start the container. I'm happy to discuss this more, feel free to reach out at evertheylen@gmail.com. I'm particularly interested in trying automated ways to try to break out of a container (like https://github.com/brompwnie/botb https://github.com/brompwnie/botb), this would benefit any containerization project.
sheerun 1y ago
Exactly this, with note that due ecosystem and history of software, setting up such environment is either really hard or relatively expensive
fph 1y ago
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.

by roenxi 1y ago

fsflover 1y ago

> 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.

mikepurvis 1y ago
How does it avoid the sharing headaches that make the ergonomics of snaps so bad?
- fsflover 1y ago
  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-your-qubes/ https://www.qubes-os.org/news/2022/10/28/how-to-organize-you..., https://blog.invisiblethings.org/2011/03/13/partitioning-my-digital-life-into.html https://blog.invisiblethings.org/2011/03/13/partitioning-my-...
  - mikepurvis 1y ago
    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/ 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.
    - orblivion 1y ago
      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.
    - orblivion 1y ago
      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.
orblivion 1y ago
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/ 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 1y ago
  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 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 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 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 https://github.com/QubesOS/qubes-issues/issues/9755
  - orblivion 1y ago
    I keep hearing different things about how well containers can isolate. I guess the "on their own" caveat is the important one. I don't really know how they work. Hearing not to rely on it from the developer of secureblue is pretty strong case. Thanks.

christophilus 1y ago

Similar, but in a podman container which shares nothing other than the source code directory with my host machine.

evertheylen 1y ago
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/ https://evertheylen.eu/p/probox-intro/
- christophilus 1y ago
  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/src/pod/pod.sh 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.
  - evertheylen 1y ago
    Yeah props to the `pasta` tool, it solves a specific problem really well. Nice script! I considered a similar approach that's based on "magic" files in the filesystem before, but it was difficult to get the security right. In your case I believe a malicious script can just overwrite .podman/env and it will be sourced by the host the next time you start the container. I'm happy to discuss this more, feel free to reach out at evertheylen@gmail.com. I'm particularly interested in trying automated ways to try to break out of a container (like https://github.com/brompwnie/botb https://github.com/brompwnie/botb), this would benefit any containerization project.

sheerun 1y ago

Exactly this, with note that due ecosystem and history of software, setting up such environment is either really hard or relatively expensive

fph 1y ago

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.