Mbox – A lightweight sandboxing mechanism(pdos.csail.mit.edu)
pdos.csail.mit.edu
Mbox – A lightweight sandboxing mechanism
http://pdos.csail.mit.edu/mbox/
24 comments
> naming: pkgfile mbox || echo looks like a good name
Next time try google/duckduckgo/bing instead of the narrowest tool you can think of. ;)
Next time try google/duckduckgo/bing instead of the narrowest tool you can think of. ;)
Thank you for this! I've been looking for a tool like this for a while (up until yesterday too), I'm glad it has been done.
I'd like to ask, are there any caveats?
I'd like to ask, are there any caveats?
http://pdos.csail.mit.edu/mbox/mbox-latest.amd64.deb doesn't exist btw.
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/
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/
"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.
(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.
Arch package in AUR:
https://aur.archlinux.org/packages/mbox-git/
https://aur.archlinux.org/packages/mbox-git/
Seems like poor naming, what with the mbox file format(s).
When I saw the title I thought it was about sandboxing email attachments or something like that.
Here I was reminded of my years of LaTeX torments with "error: underflow mbox" or similar.
I thought they found a way to use mbox format to sandbox execution
How about we call it "Paper".
>At the end of program execution, the user can examine changes in the sandbox filesystem, and selectively commit them back to the host filesystem.
This is a cool idea.
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 very secure.. I can't run anything.
./configure
make
./mbox ls
Stop executing pid=20987: It's not allowed to call mmap on 0x400000
Same here regardless of the binary on two different Fedora/Debian nodes ..
Ubuntu 12.04 here.
I suspect (haven't checked!) this is actually Ubuntu kernel not allowing mbox to do what it tries to do. See https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening
Same error here, but `ls' works:
./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
Linux colossus 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 GNU/Linuxinteresting, 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]
[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
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
Can dtrace do sandboxing the way ptrace can? I didnt think it could.
It would probably be possible using destructive actions (e.g. use raise() to kill the process if it tries to do something bad). It would require root and not be easier than using OS X's built-in sandbox (i.e. if you need to allow access to some Mach services for some APIs to work, that still needs to happen regardless of what you're using to sandbox), but it could potentially be more secure, as OS X doesn't otherwise support limiting syscalls to a small set like seccomp on Linux.
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.
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.
The benefit mbox has over unshare+aufs is that mbox doesn't require root privileges.
Sandboxie (http://www.sandboxie.com/) is a similar tool for Windows.
I love sandboxie but an open source solution would be really nice to have.
apt-cache search mbox | wc -l
82
[deleted]
No more disconnected than the 82nd non-academic who named a program mbox.
'Disconnected'?
$ apt-cache search mbox | tail -1
libetpan16 - mail handling library
That's not quite the same, from man apt-cache(8):
search regex... search performs a full text search on all available package lists for the POSIX regex pattern given, see regex(7). It searches the package names and the descriptions for an occurrence of the regular expression and prints out the package name and the short description, including virtual package names.(...) if --names-only is given then the long description is not searched, only the package name is.
Interestingly aptitude search and apt-cache search --names-only doesn't give quite the same results on my box (apart from the fact that aptitude also lists 32bit "i386" packages). But they're almost the same.
As for the names:
search regex... search performs a full text search on all available package lists for the POSIX regex pattern given, see regex(7). It searches the package names and the descriptions for an occurrence of the regular expression and prints out the package name and the short description, including virtual package names.(...) if --names-only is given then the long description is not searched, only the package name is.
Interestingly aptitude search and apt-cache search --names-only doesn't give quite the same results on my box (apart from the fact that aptitude also lists 32bit "i386" packages). But they're almost the same.
As for the names:
$ aptitude search mbox|grep -v i386 -c
24
$ aptitude search mbox|tail -1
p yahoo2mbox - Retrieve and store Yahoo! Groups messagesGah. Well, apply it to the first library named mbox that is not actually related to the mbox file format. My only point is that there are a lot of things called mbox. I don't see why we're singling out academics for criticism. People overload good names.
The first person to make something mbox that wasn't the format is the main culprit, but people after him are certainly not blameless either.
Does this have anything to do with Linux containers (lxc)?
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.
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.
I'm calling it now - such a project should be called "Mocker".
Actually, this is really a good idea. I hadn't realized that non-root users can't start their own Docker images, which I think could be a killer application. Perhaps if the overhead from something like Mbox is low enough, this could be feasible. As it is, I'm not sure I'm willing to fork over the extra ~20% overhead, just to have my applications running in a sandbox, but this could be a good method to distribute complete environments.
Actually, this is really a good idea. I hadn't realized that non-root users can't start their own Docker images, which I think could be a killer application. Perhaps if the overhead from something like Mbox is low enough, this could be feasible. As it is, I'm not sure I'm willing to fork over the extra ~20% overhead, just to have my applications running in a sandbox, but this could be a good method to distribute complete environments.
For some applications I would be more than willing to accept 20% overhead in exchange for perfect security. Still better than setting up dummy virtual boxes.
Not sure it is perfect security. There are race conditions with ptrace sandboxes. Have not read the paper yet to see if they mitigate somehow with seccomp.
Non-root users can start their own Docker images, if you change the permissions on the UNIX socket.
You might as well give them password-less sudo. Also, why are you changing permissions on the socket at all? The default is 660 which seems perfectly fine to me, if it's currently 666 you just gave everything on your box free root access.
Read this https://github.com/dotcloud/docker/issues/1369
Read this https://github.com/dotcloud/docker/issues/1369
...because this really won'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 / improvements, and can only encourage greater adoption of their ideas.
Slides end with a few questions:
> 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?
> 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?
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"
https://news.ycombinator.com/item?id=7213347
https://news.ycombinator.com/item?id=7213347
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.
the point is that mbox only uses seccomp with -s and most of it (ie the rest) is what fakeroot does already.
Very cool project; really terrible name.
The mechanism seems similar to PRoot ( http://proot.me/ ) which uses ptrace to intercept filesystem operations to create a userspace chroot.
I wonder if there's value in creating a library for intercepting filesystem operations via ptrace...
I wonder if there's value in creating a library for intercepting filesystem operations via ptrace...
[deleted]
Would this work well for sandboxing python? I want to allow users some light scripting to manipulate their data.
I'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.
Too bad both the deb link and makefile are broken.
Too bad both the deb link and makefile are broken.
Some people still run on 32bits machines. Time to git clone and make*.
post clone update: no i686 support.
post clone update: no i686 support.
I like it!
I particularly like to use mbox for redirecting modification to another directory. For example,
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.