Mbox – A lightweight sandboxing mechanism

I am the author of mbox. Since I got too many emails regarding mbox, here are a few things to clarify.<p><pre><code> - naming: pkgfile mbox || echo looks like a good name - support: sorry, I don&#x27;t have Mac or Windows. </code></pre> I particularly like to use mbox for redirecting modification to another directory. For example,<p><pre><code> $ mbox -- git checkout file </code></pre> You can checkout a file without overwritting the current file. You can imagine tons of usecases in this vein. Of course, blocking networks, restricting accesses of other directories, and rootless pkg installations are cute. However, to be a mature tool, I have to admit that there are lots of engineering works left -- support of 32bit .. compatibility layers .. still lots of corner cases.

Seems like poor naming, what with the mbox file format(s).

&gt;At the end of program execution, the user can examine changes in the sandbox filesystem, and selectively commit them back to the host filesystem.<p>This is a cool idea.

Out of curiosity, why choose for the name a term that has been around for nearly 40 years and is associated with something very different?

Hmm. Seems <i>very</i> secure.. I can&#x27;t run anything.<p><pre><code> .&#x2F;configure make .&#x2F;mbox ls Stop executing pid=20987: It&#x27;s not allowed to call mmap on 0x400000 </code></pre> Same error no matter what executable I try. I&#x27;m assuming that isn&#x27;t by design?

interesting, i agree with the bad choice of nomenclature though.<p>I wonder how hard it would be to port it to dtrace (also dtrace would defeat the not needing root requirement).<p>although macs already include a sandbox[1] i find it everything but intuitive to use. it&#x27;s already ridiculously complicated to setup. see ironfox as reference [2]. since you have to allow all sorts of mach port process execution pasteboard mach port access, etc.<p>check this app, which is allowed to play music and access the clipboard, but not access the internet. [3]<p>[1] <a href="https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/sandbox-exec.1.html" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;library&#x2F;mac&#x2F;documentation&#x2F;Darwin...</a><p>[2] <a href="https://www.romab.com/ironfox/IronFox-1.5-beta.dmg" rel="nofollow">https:&#x2F;&#x2F;www.romab.com&#x2F;ironfox&#x2F;IronFox-1.5-beta.dmg</a><p>[3] <a href="https://gist.github.com/03a481b6d39912b33d52" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;03a481b6d39912b33d52</a>

It would be interesting to run a benchmark. My impression is that ptrace interceptions would add a significant overhead but I can be wrong. Still, it looks like a great project.<p>Alternatively they could use unshare and aufs to overlay another filesystem on top of a read-only root.

Sandboxie (<a href="http://www.sandboxie.com/" rel="nofollow">http:&#x2F;&#x2F;www.sandboxie.com&#x2F;</a>) is a similar tool for Windows.

<p><pre><code> apt-cache search mbox | wc -l 82 </code></pre> Ouch. How disconnected from the real world can academics get?

Does this have anything to do with Linux containers (lxc)?

...because this <i>really</i> won&#x27;t conflict with the obsolete email storage format, right?

Kudos to the authors for releasing their source code on github. The code may have some rough edges at the moment, but putting it on Github is a great way to encourage collaboration &#x2F; improvements, and can only encourage greater adoption of their ideas.

Slides end with a few questions:<p>&gt; Why 20% on tar? just rewriting path arguments doesn&#x27;t seem to be demanding work.<p>Is most of that the overhead from syscalls being filtered by seccomp&#x2F;BPF?

Definitely looking forward to seeing this progress. It certainly seems to fill a void especially in a world where it is quite common to share command line tools as seen earlier today in the post about &quot;hr for your terminal&quot;<p><a href="https://news.ycombinator.com/item?id=7213347" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7213347</a>

<a href="http://fakeroot.alioth.debian.org/" rel="nofollow">http:&#x2F;&#x2F;fakeroot.alioth.debian.org&#x2F;</a>

Very cool project; really terrible name.

The mechanism seems similar to PRoot ( <a href="http://proot.me/" rel="nofollow">http:&#x2F;&#x2F;proot.me&#x2F;</a> ) which uses ptrace to intercept filesystem operations to create a userspace chroot.<p>I wonder if there&#x27;s value in creating a library for intercepting filesystem operations via ptrace...

Would this work well for sandboxing python? I want to allow users some light scripting to manipulate their data.

I&#x27;m guessing that this only works with dynamically linked binaries, similar to LD_PRELOAD-based solutions?

I have been waiting for an app that does this for a long time.<p>Too bad both the deb link and makefile are broken.

Some people still run on 32bits machines. Time to git clone and make*.<p>post clone update: no i686 support.

I like it!