I'm a little disappointed after reading the page. I had hoped it would do more and require no manual configuration. It uses chroot and says that it will autodetect library dependencies. That's great, but what about dlopen()'ed libraries? You can't detect those. What about data files? Can't detect those either. You'll have to manually specify them as dependencies.

You could handle dlopen() by:

- have parent isolate process monitor a dir in the chroot env. If it sees a file appear (with no .tmp suffix) it adds any .so files which are listed in the file (one per line) then removes the file

- set a LD_PRELOAD shim in the child process to hook dlopen() to write the filename to a .tmp file in the monitored dir (and then flush/close/rename/loops until file gone, then loads the .so)

Protecting data files is part of the point. You could try hooking some open/stat calls via LD_PRELOAD and make them available in the chroot if they are world-readable I guess.

When building it if you have a build error about gelf.h install the libelf-dev package.

I think the point is that it works kind of like Jail, but with the ease of use of sudo. Sometimes you might have to grant access to additional resources, but under many circumstances you can execute untrusted executables or work with untrusted data _without_ setting up a jail for each instance.

If you want to have a process that runs constantly in its own environment without even knowing that it is being crippled, jail may be the better choice. But for spontaneous spawning of suspicious scripts, this seems like a great tool.

Exactly. This is a dynamic tool, a jail is a statically configured thing that generally needs architecture support from the jailed app to work.

And what's with the BSD vs. Linux bit? FreeBSD and Linux are, in fact, precisely the two launch platforms for this tool. I don't see any favoritism at all...