I've been recently investigating for the best way to implement a Protected/Secured Execution Environment that would allow me to "upload" some code into that environment and block any kind of output (from the code execution) towards the Operating System - this way, if the code has buggs that would compromise the system, nothing would get "damaged". So far, I figured out that the most common solutions are:

  • Sandboxing
  • Virtual Machines
  • File Versioning Systems (e.g. Partitioning)

However, all of the above have following disadvantages, respectively:

  • functionality is limited
  • no support for reproduction or committing
  • no mechanisms to check changes made by different processes

So, I figured out by reading some articles that the best way to achieve this would be using a Virtual File System (VFS) and FUSE. Am I correct, or are there any better solutions?

Concerning the VFS and FUSE: What is the best (supported) Python implementation for this? fusepy?

1 Answer 1


The easiest way to create a "protected execution environment" is to just execute as an unprivileged user. The process can then only make changes to things the user has permission to change, which if you create a user specifically for secure testing, will be essentially nothing. Adding and deleting users is a single command.

The only reason this method would not be viable is if the process requires superuser privileges. In this case, you must use some kind of special sandbox or virtual machine. "Sandboxes" in general do not necessarily mean superuser privileges are viable, but they may (q.v. man chroot).

I figured out by reading some articles that the best way to achieve this would be using a Virtual File System (VFS) and FUSE.

I'm not sure why you think this. A virtual file system is still just a filesystem, so it does not offer any kind of security WRT the executables in it. This is as "secure" as mounting a USB stick (containing a filesystem) and then running an executable stored on it. Just because the executable (or, in the case of python, a script/bytecode) is stored on a removable device (or a VFS) does not protect you from anything at all.

Likewise, I do not see how "File Versioning Systems (e.g. Partitioning)" offer any kind of security for the host system, for the exact same reason. That's not their purpose, BTW.

WRT looking for something that overcomes the disadvantages you list:

  • "no support for reproduction or committing" If by "no support" you mean it's not possible, of course it is possible. You can use whatever methodology you would normally use. If by "no support" you mean a VM doesn't include some kind of mind reading software, that is correct. Mind reading requires additional hardware ;)

  • "no mechanisms to check changes made by different processes" Ditto the last point. If you need to observe what a process is doing, you can do it however you would normally do it -- strace, profiling, whatever. There may be specialized sandboxes that do do this, but I think they will be specialized along particular lines.

On that front, I'm not a python user, but a quick google led to SandBoxedPython. I don't know if anything there includes tools to do tracing for you, but if the code you want to test is python, that seems a good starting place.

  • you got it completely wrong... take a look at this paper citeseerx.ist.psu.edu/viewdoc/summary?doi= Nov 21, 2013 at 22:46
  • 1
    @bgs No, I'm afraid you got it completely wrong. Goldilocks's answer is correct. I suspect you misread that paper. The system it describes does not rely solely (or even mainly) on a virtual filesystem, but on a sandbox. Nov 21, 2013 at 23:43
  • sorry, maybe I did. But also, maybe I did not explain myself well (even I have a little trouble explaining what I would like to achieve). So, let's say I have a device running Linux that is supposed to be sniffing network packets are reacting when, e.g. it sees 3 HTTP packet from a specific host. Also, apart from the standard management components of this device (e.g. R/W network and I/O) I'd like to have this Protected Execution Environment that connects to the I/O (e.g. using handlers) so the code described above runs automatically when it sees those 3 HTTP packets. Nov 22, 2013 at 15:13
  • Now, why am I consistently talking about the protected env.? Because if I want to run a highly complex code that I'm not sure that if is going to compromise my device, since it is running inside that env. nothing is going to be written on the physical env. because the protected env. is supposed to block any writting on the network or change the I/Os. Nov 22, 2013 at 15:13
  • If this involves networking you want a VM. There aren't really any drawbacks to that method; anything you can do with regard to tracing, logging, replicating, etc. normally you can probably do in a VM too.
    – goldilocks
    Nov 22, 2013 at 15:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .