Lately I have been thinking about methods to provide a stripped down, secured environment for running untrusted code on GNU/Linux. With this post I would like to present you with the first results of my research.
ujail - brief introduction
I have chosen
ujail as the name for the technique I am proposing. ujail stands for micro jail in userspace and, in itself, describes the concept briefly. The main idea is to have a userspace process monitor system calls of one of its childs and emulate some calls, if needed. This is done using ptrace and namely both PTRACE_SYSEMU and PTRACE_SYSCALL.
The ujail process should not be able to monitor syscalls, like strace does, but also intercept and emulate them.
This sounds a lot like user mode linux (uml), but the method is different. Whilst uml comes with a complete kernel, emulates all system calls and this way provides a virtualized system, ujail is intended to only emulate some systemcalls, without emulating the kernel.
Revisiting PTRACE_SYSCALL & PTRACE_SYSEMU
To better explain how the ujail technique works I would like to have a quick look at PTRACE_SYSCALL and PTRACE_SYSEMU again.
PTRACE_SYSCALL allows a userspace process to be notified whenever a traced process enters or leaves a system call. This means that two notifications are normally sent: one before system call entry and one afterwards. Even though one is able to change the parameters of system calls this method does not allow system calls to be fully emulated (think virtual filesystem here).
PTRACE_SYSEMU on the other hand provides one notification on syscall entry and expects the receiver of the notification to emulate the syscall. This method alone sounds great, but this also means that memory allocation needs to be emulated too, which is quite complex in userspace.
A hybrid of PTRACE_SYSCALL & PTRACE_SYSEMU
Now on to the concept behind ujail. The method I am describing works by calling PTRACE_SYSEMU for a specific process and this way taking over emulation of all system calls. However, some system calls are complex to emulate in userspace, and so a hybrid of both PTRACE_SYSEMU and PTRACE_SYSCALL is needed. In short this works by checking whether the syscall needs to be emulated when the PTRACE_SYSEMU event is received.
Now one way is emulating the syscall, filling the processes' registers and resuming execution of the process. This is simple and straight-forward.
The second way is forwarding the system call to the kernel. The problem here is that calling the syscall in the monitoring process will make the new resources available to that very process, and not the process to be jailed. This is where the hybrid method kicks in.
The proof of concept code creates a backup of the next instruction to be executed along with a copy of the instruction pointer at this point and patches it with the opcodes for "int $0x80", causing the syscall to be made again. After that it resumes execution with PTRACE_SYSCALL and waits again. The first event to be received now is the program leaving the emulated system call, which can be ignored. Resuming yet again will give use two PTRACE_SYSCALL events, one for syscall entry and one for syscall exit.
The first event is not really interesting, but at the second event the opcode backup is restored and the eip set from the saved value. Now the kernel has handled the syscall and the result is ready for the child process. A final call of PTRACE_SYSEMU resumes execution of the child and waits for the next syscall.
Proof of concept
The proof of concept code can be downloaded from its
bazaar branch at launchpad.net. It is intended to be used on i386 systems only and works with simple programs, but is known not to work with anything using fork, vfork and most likely will not work for binaries using threading.
Finally, I would like to thank
Pradeep Padala for his "Playing with ptrace" articles
[0][1], which were fun to read and worked as a great introduction of ptrace for me.
Now there is only one thing left to say: if you are interested in this method, see loopholes or problems or want to contribute, please go ahead and contact me:
debian at sp dot or dot at
Yesterday I was trying to get some of my old keybindings (from awesome 2.x) to work on awesome 3.4 and it was awful the process.
With 2.x I worked with 
A customer called me a while back.
They have a pretty high-end NAS (2U server with external disk
enclosure) that they use for most of their needs: both document and
other storage for management types, as well as storage for their EDA
cluster. People familiar with EDA tools will know that they are pretty
disk intensive. They tend to require shitloads of diskspace, preferably
at high performance.
The problem was that extending the storage space of this high-end NAS
device is rather expensive. Supported disks only come at 300G units with
prices that are higher than the cheap TB disks available today for the
desktop market; and while the price and performance of those disks is
worth it for the EDA requirements, the number of people storing
documents and similar on the same device is not so high that performance
would be an issue.
Thus, what they wanted was a cheap solution to augment, rather than
replace, their current storage solution, with the focus being on low
cost at the possible expense of performance and, since bacula runs well
there, reliability.
They were quite surprised when I offered them a solution based around
a QNAP device; they had expected a price, without hard disks, of about
three to four times the price of the QNAP, and therefore were very happy
with this suggestion. Unfortunately, the devices produced by this
manufacturer that are supported by Lenny, the current Debian stable
release, were EOL'd just before we
placed the order; however, their replacements will be supported by
Squeeze, the next release, and with a bit of help from Martin Michlmayr,
we were able to install Lenny with a somewhat more recent kernel. This
drove the price up somewhat, both because the newer devices are a few
tens of euros more expensive, and because we agreed to pay Martin to
prioritize work on the specific device that we'd need, so that we
wouldn't have to wait for him to get around to it.
As of this Thursday, the device, which had finally arrived after some
initial delays, has been installed. Unfortunately, one of the disks that
they'd bought was DOA; but they had
the foresight to buy five, rather than four, disks, so that was not a
major problem. In fact, the only real issues that I ran into were this
one 
Run 
This is a question that 
I've been watching some good films recently. Two I especially liked.
Still, I felt so much more at home in Tulpan. Kept pausing it to check out
how the family had their 
I have an imaginary automobile. It is the finest hybrid
of German and Japanese engineering. It has a peppy little
engine and a turning radius so small it would make a baby
camel cry, and a six-speed manual transmission, and it is
powered by the urine of vegan bears.
My imaginary father asked me why I would possibly want to
buy an imaginary car with a manual transmission. Obviously,
whichever marketing campaign brainwashed him in the first
place wasn't strong enough on the memetics, because after
borrowing my imaginary car, he shut the hell up. You see,
it's considerably more fun to drive than an automatic.
There are other benefits as well, of course. The primary
one is that the transmission does what I want.
An automatic transmission is configured for maximum comfort ,
so it wastes a lot of power when shifting. With a manual,
you can slip from gear to gear with minimal clutch time, or
in some cases, if you're feeling sassy, without using the
clutch at all. You can control your engine speed so that
your shift will be just as smooth as an automatic without
the egregiously long clutch disengagement or shift overlap.
You also can see the road in front of you, so you're always
going to be smarter than an automatic transmission, unless
you don't understand how slopes work or what collisions with
other cars mean to your well-being.
Now some NRA member is going to point out that you can get
a shift kit and tweak your automatic to be less awful.
While spending money on this type of thing sounds like
a great idea, a shift kit is not going to bring an
automatic into the same league as my car. I can still
start the car when the battery's dead. I can get higher
fuel efficiency (vegan bears don't exactly urinate for
free). I can shift into fifth gear, and coming from a
full stop, drive up a hill without stalling (this is
particularly useful when a squirrel has gnawed the teeth
off of all your other gears). Furthermore, shift kit
or not, an automatic is absolutely no fun.
Someday, when transmissions have advanced into the realm
of liquid hyperspace buckminsterfullerene cones that
commune with the unicorns, and they'll have cameras and
radar feeding the car's computer with useful information
about its surroundings so it can make intelligent shift
decisions faster than a human. Then I'll have to choose
between saner and more fun. That era has not yet arrived.
This is a lousy metaphor for debhelper.
Dear lazyweb: I am in a dreadful situation! I need to secure
e-mail communication between five types of users:
Dear life,
