Quarantine for untrusted applications
There are many buggy applications out there, and there's very
little that prevents one application to do very bad things to the user
running it. Buffer overruns in applications are pretty common (see
buffer overrun in pine, for example), and we do not want malicious
incoming mail to delete user's files, do we?
What can we do with that? Fixing all applications is hard, as some
of them are closed-source, and there's much too much open-sourced ones.
One possible solution is to design sandbox (or quarantine), and run
untrusted applications inside sandbox. When sandbox is properly setup,
buffer overrun in application is not that dangerous. It will
still be able to harm data it is working with, but it can no longer
broadcast your .ssh/identity to the world.
There are quite a few projects that are trying to deal with it:
- (1) Goldberg, Wagner, Thomas, Brewer: Janus: A secure
environment for untrusted helper applications: confining the wily
hacker. It uses ptrace-like interface to trace untrusted executable
and not let it do dangerous things. It has slight problem:
it does not work. Due to volatile memory problems,
application is able to circumvent protection. [Estabilishing shared
memory between two programs, then doing
open(pointer_to_shared_memory), and rapidly changing content of
shared memory. If you are lucky, kernel sees other path than
- (2) Dan, Mohindra, Ramaswami, Sitaram: ChakraVyuha:
A Sandbox Operating System Environment for Controlled Execution of
Alien Code. They put all their changes into linux kernel. I tried to
contact IBM to get sources, but did not get them.
- (3) User
mode linux: is linux emulator on top of linux. With some
modifications, it could be used as sandbox. Getting the networking
right would be pretty hard to do without root priviledges, through.
- (4) myself: podfuk
is system for placing filesystems into userland. In combination with
root priviledges and setuid chrooter, it could be used to restricting
- (5) Deny and allow. Other method how to do sandbox would be to add
capabilities like "user can read his own files". Then, you run
untrusted applications without those capabilities. That would not
work with applications more complicated than grep. (That was deny
part). Now, if app wants to do some more complicated operation, it
has to nicely ask sandbox to do the work for her. (But you don't
want to modify each application, do you). LD_PRELOAD is the way to
- (6) subterfugue is python
(ouch) system that uses ptrace() to do various things to
applications. Rot13-ing all data apps write using write syscall is
example of its power. It is powerfull enough to properly sandbox
application. Volatile memory races can be solved by copying data
into memory that is read-write to sandbox, but read-only to
sandboxed application. And that can be done with some
trickery. This is currently my favourite toy. Its
disadvantage is that it is slow -- python is
Details about subterfugue solution
Problem with ptrace() is than in-memory arguments can change
between sandbox checking them and kernel executing them. (See example
near janus.) My solution looks like this:
- /tmp/mmap-safe file is opened read-only as filehandle
123. This handle is passed to untrusted application.
- When application does first syscall, mmap() of handle 123 into
0x3f000000 area of memory is executed on its behalf.
- When application does syscall like open("./foo"), name is
resolved into "/bar/foo", which is then written to
/tmp/mmap-safe. Pointer to "./foo" is changed into
0x3f000000 (or similar), which now contains
"/bar/foo". (It is tiny a bit more complicated than this, as
we want multiple apps to be able to enter syscall at once, but you got
- Application is prevented from tampering with handle 123. (Module NoClose123)
- Application is prevented from tampering with memory at 0x3f000000. (Module NoMunmap)
I believe this is safe. It has few problems, through:
/proc/self is symlink which depends on who is
looking. /proc/XXX/fd/X is symlink which says it is pointing
to some bogus place, but actually works if you try anyway.
My "gnome sandbox" currently looks like this:
- subterfugue has option to put its own output onto fd3, so that it is
not mixed with stdout nor stderr of task being sandboxed.
- PathSandbox trick reads config file. It is able to reread config
file at will (and will reread config file on SIGUSR1 or SIGUSR2).
- when unallowed operation is encountered, question is written onto
fd3. Gnome part parses output on fd3, and asks user the question. If
operation is to be allowed, SIGUSR1 is sent, otherwise SIGUSR2 is
sent. [This has big advantage of being able to use manually: killall
-USR1 python is not that difficult to do manually.] Config file is
- gnome frontend may decide to modify config file when it is asking
question. That's ok: config will be reloaded by python backend.
It has big advantage of gnome part (written in C) being cleanly
separated from python part.