Before diving into this, I want to say that sandboxing is VERY useful! But it isn’t the solution to everything.

Sandboxing is great, but sandboxing is a pain to use… The issue is that there is almost always a time when multiple executables have to share a machine. When there are too many moving parts, we need to change the way we approach security.

Our solution is kind of an anti-sandbox: everything can access everything, except for a couple of protected resources.

How it works

I think the easiest way to explain this is with an example.

So, in this example, we have a couple of executables, the server, test.sh, and support.sh.

The server accesses Postgres, which in turn accesses the DB.

test.sh can access the GPU and push data to the server.

And support.sh is a helper for test.sh.

Note that in this example, the server accesses Postgres over IP and test.sh accesses the server over IP.

Using VMs

We can start by trying to secure this with VMs to sandbox the executables.

So, the server would get its own VM.

Postgres and the DB would get their own VM.

And, the test.sh, the GPU, and the support.sh would all be in a VM.

Each VM would access the others by poking a hole in its firewall and allowing IP access.

The issue is that the way this is implemented would violate the whole reason of using VMs. Since test.sh needs to access support.sh, both executables are running in a single VM.

Having two executables in a single VM negates the entire reason for using VMs in the first place, since it no longer provides sandboxing.

One real world example of this is Postgres itself. When it runs in the background, it mostly has a script that launches Postgres as a daemon on your system. This is just an example, but you will always have executables on your system that interact with each other (that’s what makes it a system).

Our Solution

Our solution is to protect only a few specific resources rather than protecting everything.

So, in this example, the DB and the GPU would be protected resources.

Then only Postgres can access the DB, and Postgres can only be accessed by the server.

The GPU can be accessed only by test.sh, and test.sh can access only the servers IP endpoint.

And, support.sh can access anyone since it can’t really access any protected resources.

Conclusion

In the end, sandboxing is great, but as I said before, it’s a pain. That’s why we came up with our current solution.

If you want to do sandboxing, go for it! We just didn’t want to deal with the issues with sandboxing.