I am the author of mbox. Since I got too many emails regarding mbox, here are a few things to clarify.
- naming: pkgfile mbox || echo looks like a good name
- support: sorry, I don't have Mac or Windows.
I particularly like to use mbox for redirecting modification to another directory. For example,
$ mbox -- git checkout file
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.
"pkgfile jpeg" || echo looks like a good name. Maybe not.
(I don't have pkgfile but I think the above command would echo the string). I do understand that naming a program is every day harder, but mbox is a really famous format, the de facto standard for storing e-mails. Please consider a different name for your impressive program.
So far mbox is pretty awesome. Installed a bunch of rootless memory scrapers with a regular user account to see what it can do. Another, ephemeral sandbox I use is PrivExec http://www.onarlioglu.com/privexec/
./mbox ls
test
> /tmp/sandbox-14587
./mbox -- wget google.com
Stop executing pid=14629: It's not allowed to call mmap on 0x400000
Sandbox Root:
> /tmp/sandbox-14625
BTW, I'm on Arch:
Linux colossus 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 GNU/Linux
interesting, i agree with the bad choice of nomenclature though.
I wonder how hard it would be to port it to dtrace (also dtrace would defeat the not needing root requirement).
although macs already include a sandbox[1] i find it everything but intuitive to use. it'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.
check this app, which is allowed to play music and access the clipboard, but not access the internet. [3]
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.
Alternatively they could use unshare and aufs to overlay another filesystem on top of a read-only root.
This is addressed in the paper. Performance overhead is in the ballpark of 10-20%. They are able to improve on the performance of a purely ptrace-based sandbox by using seccomp to ensure that only the syscalls that need to be intercepted are sent to ptrace.
The benefit mbox has over unshare+aufs is that mbox doesn't require root privileges.
Not exactly, from what I can tell. This lets you run an individual process in a host environment, but using fine-grained privilege restrictions, and some judicially inserted virtualization. LXC runs hosts in a complete OS-level virtualized environment, more like its own Linux instance, which is a bit more complete virtualization (not always desired for a single process).
A Solaris / OpenSolaris / Illumos analogy is to compare running a process in a new Zone (which is like a FreeBSD Jail or a Linux LXC/OpenVZ container), versus running a process in an existing Zone but using ppriv(1) to selectively drop privileges usually given to processes by default, such as network access, file read/write, exec, etc. One is in what looks like its own OS instance, while the other is in the parent OS instance but sandboxed. The analogy isn't quite complete because the ppriv(1) approach doesn't lie to processes that try to violate the permissions like Mbox does; instead it just denies their attempts to do something that violates policy (such as opening a file). So, it might cause sandboxed processes to crash, rather than letting them complete with faked completion.
Not really; mbox uses seccomp-bpf to filter system calls, from userland, using unprivileged users. A very ambitious project to build on top of mbox might be an even lighter-weight Docker-alike using userland system call interposition instead of Linux containers.
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 / improvements, and can only encourage greater adoption of their ideas.
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 "hr for your terminal"
If you want to provide a redirected environment for a presumptively non-malicious process, fakeroot works fine. It's not a secure sandbox, though, because it's based on intercepting system calls with LD_PRELOAD, and a process that wishes to can avoid being intercepted in that manner, since it's just enforced by the shared-library loader. So processes that are statically linked, or that have direct syscalls compiled in, will bypass the LD_PRELOAD replacements. The seccomp mechanism, by contrast, is enforced by the kernel.
[+] [-] tsgates|12 years ago|reply
[+] [-] riquito|12 years ago|reply
(I don't have pkgfile but I think the above command would echo the string). I do understand that naming a program is every day harder, but mbox is a really famous format, the de facto standard for storing e-mails. Please consider a different name for your impressive program.
[+] [-] dobbsbob|12 years ago|reply
So far mbox is pretty awesome. Installed a bunch of rootless memory scrapers with a regular user account to see what it can do. Another, ephemeral sandbox I use is PrivExec http://www.onarlioglu.com/privexec/
[+] [-] stelonix|12 years ago|reply
I'd like to ask, are there any caveats?
[+] [-] znowi|12 years ago|reply
https://aur.archlinux.org/packages/mbox-git/
[+] [-] Mithaldu|12 years ago|reply
Next time try google/duckduckgo/bing instead of the narrowest tool you can think of. ;)
[+] [-] tghw|12 years ago|reply
[+] [-] mdpane|12 years ago|reply
[+] [-] XaspR8d|12 years ago|reply
[+] [-] userbinator|12 years ago|reply
[+] [-] colinbartlett|12 years ago|reply
[+] [-] friendzis|12 years ago|reply
[+] [-] oscargrouch|12 years ago|reply
This is a cool idea.
[+] [-] jlgaddis|12 years ago|reply
[+] [-] nl|12 years ago|reply
[+] [-] agateau|12 years ago|reply
[+] [-] thiagoc|12 years ago|reply
[+] [-] joshbaptiste|12 years ago|reply
[+] [-] rjzzleep|12 years ago|reply
I wonder how hard it would be to port it to dtrace (also dtrace would defeat the not needing root requirement).
although macs already include a sandbox[1] i find it everything but intuitive to use. it'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.
check this app, which is allowed to play music and access the clipboard, but not access the internet. [3]
[1] https://developer.apple.com/library/mac/documentation/Darwin...
[2] https://www.romab.com/ironfox/IronFox-1.5-beta.dmg
[3] https://gist.github.com/03a481b6d39912b33d52
[+] [-] justincormack|12 years ago|reply
[+] [-] zimbatm|12 years ago|reply
Alternatively they could use unshare and aufs to overlay another filesystem on top of a read-only root.
[+] [-] agwa|12 years ago|reply
The benefit mbox has over unshare+aufs is that mbox doesn't require root privileges.
[+] [-] skeoh|12 years ago|reply
[+] [-] anemic|12 years ago|reply
[+] [-] alrs|12 years ago|reply
[+] [-] jamesaguilar|12 years ago|reply
[+] [-] cscheid|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] aabalkan|12 years ago|reply
[+] [-] mjn|12 years ago|reply
A Solaris / OpenSolaris / Illumos analogy is to compare running a process in a new Zone (which is like a FreeBSD Jail or a Linux LXC/OpenVZ container), versus running a process in an existing Zone but using ppriv(1) to selectively drop privileges usually given to processes by default, such as network access, file read/write, exec, etc. One is in what looks like its own OS instance, while the other is in the parent OS instance but sandboxed. The analogy isn't quite complete because the ppriv(1) approach doesn't lie to processes that try to violate the permissions like Mbox does; instead it just denies their attempts to do something that violates policy (such as opening a file). So, it might cause sandboxed processes to crash, rather than letting them complete with faked completion.
[+] [-] tptacek|12 years ago|reply
[+] [-] blueskin_|12 years ago|reply
[+] [-] justinsb|12 years ago|reply
[+] [-] Scaevolus|12 years ago|reply
> Why 20% on tar? just rewriting path arguments doesn't seem to be demanding work.
Is most of that the overhead from syscalls being filtered by seccomp/BPF?
[+] [-] bullfight|12 years ago|reply
https://news.ycombinator.com/item?id=7213347
[+] [-] zobzu|12 years ago|reply
[+] [-] mjn|12 years ago|reply
[+] [-] Lazare|12 years ago|reply
[+] [-] daxelrod|12 years ago|reply
I wonder if there's value in creating a library for intercepting filesystem operations via ptrace...
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] mrfusion|12 years ago|reply
[+] [-] koenigdavidmj|12 years ago|reply
[+] [-] wmf|12 years ago|reply
[+] [-] zx2c4|12 years ago|reply
It uses ptrace and seccomp-bpf.