3 ms·

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.
0cf8612b2e1e 1y ago
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.
- evertheylen 1y ago
  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.
- christophilus 1y ago
  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 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.

0cf8612b2e1e 1y ago

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.

evertheylen 1y ago
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.
christophilus 1y ago
I run the ide (neovim) in the container along with npm, cargo, my dev / test databases, etc. It’s a complete environment (for me).