2 ms·

> Passing through the FS to the host is a no-go because of subtle executable things like git-hooks that could enable sandbox escape. Could you please expand on

by exec1 3y ago

> Passing through the FS to the host is a no-go because of subtle executable things like git-hooks that could enable sandbox escape. Could you please expand on this? I’m having trouble understanding this.

exec1 3y ago
Also, while I’m at it – if you’re using VMs for isolating potentially insecure things then your threat model is obviously different. I should have mentioned that I’m using VMs mainly for practical reasons, e.g. for easily spinning up Ubuntu environments with my preferred toolset. If you’re worried about something escaping the VM sandbox via git-hooks then your use case is of course very different.
- chromakode 3y ago
  My motivation for sandboxing is to fearlessly tinker with unfamiliar dependencies without thinking too deeply about the supply chain. Starting with isolation makes it safer to experiment, which is important to me for velocity.
  - exec1 3y ago
    Fair enough. I have clarified my use case at the top of my article to reflect my threat model. I don’t use the VM to run tricksy software I don’t trust so the sandboxing argument doesn’t really apply in my case (or rather it doesn’t apply any more than when running software directly on the host). All of the software I run on my VMs is the same software I would run on my host (if the host was Linux-based).
    - chromakode 3y ago
      Likewise, fair enough. I appreciate you clarifying your threat model. I try to operate with low trust dev environments whenever possible, which is a major motivation for using VMs. It only takes one malicious npm or pip package for it to pay off.
      - exec1 3y ago
        Yeah, I hear you. I try to avoid pulling NPM packages that I don’t know so I’m not really interested in containing software for security purposes. Of course, there’s also the question of dependencies. If I’m working on a project that I trust that pulls in hundreds of NPM dependencies, I implicitly trust that the project deemed those dependencies safe to pull in. It would be impossible to always operate on the assumption that you’re potentially pulling in hundreds of malicious packages so the chain of trust has to take over at some point. However, I imagine you were more or less referring to singular projects that you don’t fully trust and like to experiment with in which case I agree with you and would probably use a VM without any kind of file sharing tbh.
chromakode 3y ago
For example, let's say I've got a git repo on a guest VM and I'm syncing the dir to the host. If I run `git push` on the host (because my ssh key is there), it implicitly runs any pre-push script dropped there by the guest, defeating any isolation.
exec1 3y ago
An addendum: if you’re worried about the guest setting up a malicious git hook that your host would then execute, then your threat model is obviously very different from mine. Perhaps I should have clarified that I’m running code that I trust inside the VM so sandbox escape is not really a security issue in my case (but rather an operational one if, for example, a misbehaving script causes havoc on the host in this way).

by exec1 3y ago

exec1 3y ago

Also, while I’m at it – if you’re using VMs for isolating potentially insecure things then your threat model is obviously different. I should have mentioned that I’m using VMs mainly for practical reasons, e.g. for easily spinning up Ubuntu environments with my preferred toolset. If you’re worried about something escaping the VM sandbox via git-hooks then your use case is of course very different.

chromakode 3y ago
My motivation for sandboxing is to fearlessly tinker with unfamiliar dependencies without thinking too deeply about the supply chain. Starting with isolation makes it safer to experiment, which is important to me for velocity.
- exec1 3y ago
  Fair enough. I have clarified my use case at the top of my article to reflect my threat model. I don’t use the VM to run tricksy software I don’t trust so the sandboxing argument doesn’t really apply in my case (or rather it doesn’t apply any more than when running software directly on the host). All of the software I run on my VMs is the same software I would run on my host (if the host was Linux-based).
  - chromakode 3y ago
    Likewise, fair enough. I appreciate you clarifying your threat model. I try to operate with low trust dev environments whenever possible, which is a major motivation for using VMs. It only takes one malicious npm or pip package for it to pay off.
    - exec1 3y ago
      Yeah, I hear you. I try to avoid pulling NPM packages that I don’t know so I’m not really interested in containing software for security purposes. Of course, there’s also the question of dependencies. If I’m working on a project that I trust that pulls in hundreds of NPM dependencies, I implicitly trust that the project deemed those dependencies safe to pull in. It would be impossible to always operate on the assumption that you’re potentially pulling in hundreds of malicious packages so the chain of trust has to take over at some point. However, I imagine you were more or less referring to singular projects that you don’t fully trust and like to experiment with in which case I agree with you and would probably use a VM without any kind of file sharing tbh.

chromakode 3y ago

For example, let's say I've got a git repo on a guest VM and I'm syncing the dir to the host. If I run `git push` on the host (because my ssh key is there), it implicitly runs any pre-push script dropped there by the guest, defeating any isolation.

exec1 3y ago

An addendum: if you’re worried about the guest setting up a malicious git hook that your host would then execute, then your threat model is obviously very different from mine. Perhaps I should have clarified that I’m running code that I trust inside the VM so sandbox escape is not really a security issue in my case (but rather an operational one if, for example, a misbehaving script causes havoc on the host in this way).