LWN: Comments on "Google's Chromium sandbox"

Google's Chromium sandbox

i3839 — Wed, 21 Oct 2009 10:36:43 +0000

Weird, works for me. Perhaps a temporary server glitch? Please try again.

Google's Chromium sandbox

SEJeff — Thu, 15 Oct 2009 21:57:21 +0000

Whenever Roland finishes polishing it up, utrace will be merged in the
kernel. utrace removes the one ptrace / process limitation.

Google's Chromium sandbox

cwitty — Mon, 12 Oct 2009 21:01:58 +0000

Sounds interesting, but:

"Forbidden

You don't have permission to access /~guido/publications/ps/secrypt07.pdf on this server."

Generic sandbox needed

cmccabe — Fri, 04 Sep 2009 20:18:15 +0000

> It seems to me that this kind of sandboxing is required by many (all?)
> programs dealing with potentially hostile data....
>
> If the kernel would provide a flexible mechanism for an application to
> limit what it can do, the threat of hostile data could be reduced.

I thought that this was what selinux was all about.

The basic idea behind selinux is that rather than using identity-based security, you use capability-based security

Identity-based security works like this: I am a process started by bob, therefore I can do everything bob can do. Capability-based security works like this: bob starts a process and gives it only the capabilities it needs to do the work it's supposed to do.

So bob runs a spell-checker program (aspell or whatever), it shouldn't have the capability to open network sockets and send messages to evilhackers.com. It's the difference between giving the application a few keys, to open the doors it needs, and giving it the whole keyring, which is what we do with traditional uid / gid based security.

It seems like what the google people are trying to do here is to reinvent the selinux concept with seccomp. I'm curious as to why. I guess selinux is difficult to set up and configure, and a lot of distributions have been slow to adopt it. Perhaps they are also trying to be cross-platform?

I'm also curious why Google is using threads rather than processes here. If you don't want to share your memory with the untrusted guy, processes are the obvious solution. As other have noted, you can always use posix shared memory if you feel the need to directly access the memory of the untrusted guy. As a bonus, you could run the untrusted processes as "nobody," and prevent them from doing a lot of nasty things -- even on a system like openBSD, where seccomp and selinux are unheard-of.

P.S.
I seem to remember that the openBSD ssh daemon was written in a similar way. There was an trusted part which ran as root, and an untrusted part which ran as a regular user.

Google's Chromium sandbox

gmatht — Sat, 29 Aug 2009 05:20:56 +0000

I am not the person to which your question was addressed (my contribution to
chrome is limited to one patch to an install script).

However, I am "interested" in packaging this for Ubuntu. I really don't have
time now, but I may drop you an email in a few months. Having an easy to use
sandbox tool would be very nice.

Google's Chromium sandbox

i3839 — Sun, 23 Aug 2009 14:49:44 +0000

As part of my bachelor project I have worked on rewriting a ptrace based jailer. The old implementation was too big and complicated, the new one is only a few thousand lines of code big. This is a generic jailer which is not racy. Among other things it prevents time-of-check-to-time-of-use race conditions, but it also prevents races between different system calls like rename and open, and symlink trickery. The current version supports Linux 2.6, but 2.4 or BSD support can be added too. Adding support for other architectures than x86 is trivial.

For its design see http://www.cs.vu.nl/~guido/publications/ps/secrypt07.pdf
The rewritten version does some things differently and doesn't yet support all features of the original one. The code isn't released yet, but we plan to release it under a BSD-like license. If interested email Guido or me (indan@nul.nu).

Google's Chromium sandbox

oak — Sun, 23 Aug 2009 08:47:41 +0000

Why not do everything required in the process (mmaps, file opens etc) then
drop into seccomp mode to run the non-trusted code that need to be
secured? This way the non-trusted code can request whatever it needs over
an already opened pipe etc. and the extra thread would then be needed only
for handling its memory allocations.

And btw, one can easily do a DOS with memory allocations. Just alloc
large enough amount of memory (but not so large that it would trigger
OOM-killer) and then constantly write over it. Device is frozen swapping
until the process is killed.

As to LD_PRELOAD and ptrace(), former doesn't catch syscalls done directly
in ASM and AFAIK ptrace is racy (if I remember correctly, this was
mentioned in the discussions about utrace).

Regarding things like Flash. Until that can be secured, this doesn't
really do browser any safer for the normal users. Most of the content on
web that non-technical people use and are interested uses Flash in some
way. Especially for media delivery. What's the point of securing a mouse
hole if the barn doors are wide open?

Generic sandbox needed

Wout — Sat, 22 Aug 2009 12:34:34 +0000

It seems to me that this kind of sandboxing is required by many (all?) programs dealing with potentially hostile data. Web data, photo's, video's, mp3's, ISO's, ... are all potentially dangerous. Some attacks are just more common then others. So you'd like all desktop applications to defend themselves. Applications need a (kernel provided) way to create their own sandbox before touching untrusted data. Approaches like Chromium's seem like engineering around a kernel limitation.

If the kernel would provide a flexible mechanism for an application to limit what it can do, the threat of hostile data could be reduced. A combination of user level chroot ("This application doesn't need anything outside this directory.") and an allowed system call mask ("This application will only use these system calls, it doesn't need the rest.") should severely limit what an attacker can do.

Google's Chromium sandbox

mingo — Thu, 20 Aug 2009 19:33:12 +0000

Does this approach work on a per process basis? I.e. do the restrictions apply to a particular process/thread while others are not impacted?

It's an engine - and as such it takes ASCII strings, turns them into a 'filter object' in essence which you can then attach to anything and pass in values to evaluate.

Note that there's nothing 'tracing' about that concept.

Right now we attach such filters to tracepoints - such as syscall tracepoints.

It could be attached via seccomp and to an untrusted process as well, with minimal amount of code, if there's interest to share this facility for such purposes.

Sandboxing made easy

man_ls — Thu, 20 Aug 2009 18:13:15 +0000

Ah, but of course -- sounds obvious once it is pointed out. Stupid dangers of memory management!

Sandboxing made easy

martine — Thu, 20 Aug 2009 16:25:15 +0000

That is in fact already how Chrome works, and yes, it is rather complicated.
See
http://dev.chromium.org/developers/design-documents/multi...
architecture

This article about the architecture used to make the HTML-decoding process
both sandboxed but still powerful enough to convert HTML into images (which
are then sent back to the trusted process).

Google's Chromium sandbox

paragw — Thu, 20 Aug 2009 14:41:46 +0000

Does this approach work on a per process basis? I.e. do the restrictions
apply to a particular process/thread while others are not impacted?

How would one deal with which process can specify which other process or
thread can do what syscalls with what arguments and is the change permanent
and localized w.r.t the target thread? How does one go about safely modifying
the restrictions dynamically - the restricted thread needs to open a FD with
user permission that wasn't in the originally specified restrictions list?

From what you described there seem to be some significant usability problems
(need to have tracing enabled, debug file system mounted, user-space access
to the filtering mechanism and per PID operation etc.) that need to be
addressed before it can become generally usable?

Google's Chromium sandbox

mingo — Thu, 20 Aug 2009 08:59:59 +0000

Btw., (and i raised this on lkml too in the past - at that time the code i referred to was not upstream yet), there's a way you could further increase the restrictions (and hence, the security) of the untrusted seccomp thread: by the use of the C expressions filter engine that is included in the upstream kernel. (right now used by ftrace and will also be used by perfcounters)

The engine accepts an ASCII C-ish expression runtime, such as:

 "fd <= 2 && addr == 0x1234000 && len == 4096"

... and turns/parses that into a cached list of safe predicaments that the kernel will execute atomically on syscall arguments. Once parsed (by the kernel), the execution of the filter expression is very fast.

Despite it being used for tracing currently, the filter engine is generic and can be reused not just to limit trace entries of syscalls, but also to restrict execution on syscalls.

This is real, working code very close to what you need. With latest -tip you can use the filter engine on a per syscall basis, and the kernel knows about the parameter names of system calls. So on a testbox i can do this:

  # cd /debug/tracing/events/syscalls/sys_enter_read

  # echo "fd <= 2 && buf == 0x120000 && count == 1024" > filter

  # cat filter 
  fd <= 2 && buf == 0x120000 && count == 1024

... and from that point on the kernel can execute that filter expression to limit trace entries that match the expression.

All you need is a small extension to seccomp to allow the installation of such expressions from user-space, by passing in the ASCII string. The filter engine can be used by unprivileged user-space as well. (but obviously the untrusted sandboxed thread should not be allowed to modify it.)

The filter engine has no deep dependence on tracing (other than being used by it currently) - it is a safe parser and atomic script execution engine that can be utilized by unprivileged tasks too and so it could be reused in seccomp and could be reused by other Linux security frameworks as well, such as selinux or netfilter.

Google's Chromium sandbox

ncm — Thu, 20 Aug 2009 02:40:07 +0000

Nah, the parent and gdb hand off. Whenever the child process sends a request for a system call, that trips a breakpoint, and gdb lets go of the child, which stalls waiting on the parent. Gdb attaches to the parent, and the parent attaches to the child and does its business. When the system call is done, the parent releases its ptrace and hits a breakpoint of its own, and then gdb parks the parent on a read call, detaches from the parent and re-attaches to the child, has it send a wakeup to the parent, and then we're back where we started.

Google's Chromium sandbox

njs — Thu, 20 Aug 2009 01:33:01 +0000

Clever approach, though it does have the minor flaw that you become unable to ever use a debugger on the main web browser guts (since only one process can ptrace() at a time).

Google's Chromium sandbox

agl — Thu, 20 Aug 2009 00:58:53 +0000

That seems like a perfectly reasonable way to allocate memory for another
process. However, we would still need non-seccomp processes to receive the
file descriptor from the socket (recvmsg) and to do the mmap. The first
process need only share the descriptor table with the untrusted process, but
the second needs to share an address space for mmap to be effective. We
merge these two processes into one and, since it shares an address space, we
call it the 'trusted thread'.

Google's Chromium sandbox

cventers — Thu, 20 Aug 2009 00:43:08 +0000

I should have been more clear about why a thread is needed. Certain operations, memory allocation for example, cannot be done in one process on behalf of another because they don't share address space.

On the contrary, I experimented with a technique to do just that. This may not be the perfect solution for Chrome's needs, but I played around with the idea of open()ing a shared memory segment on the vfs, using ftruncate() to resize it, and then sending the fd via a UNIX-domain socket to the untrusted process and allowing it to mmap() the pages.

Now, in my case, I was using this technique to allow dynamically-grown, runtime-allocated shared memory segments between untrusted processes. There are still complications (such as the need to install a SIGBUS handler since the untrusted process might ftruncate() the mmaped fd() to 0, causing the trusted process to fault when it tries to access its own mmap()), and perhaps the requirements for this kind of an implementation are not easy to satisfy for desktop applications. But it's Linux, and there's more than one way to do it. My implementation had the advantage of being architecture-agnostic, as well-behaved user-space code should be.

Sandboxing made easy

Simetrical — Thu, 20 Aug 2009 00:33:38 +0000

Apparently because you need to be able to do things like allocate memory on
the heap, and the restricted thread can't do that. So you need a trusted
thread running in the same process.

Sandboxing made easy

man_ls — Thu, 20 Aug 2009 00:14:11 +0000

This is probably a stupid question, but I have to ask. Why not use read() and write() to make the untrusted part communicate with the trusted part, via a pipe? The untrusted part (a process) could decipher the HTML, and then send the result in an intermediate form to the trusted part (another process) for it to display that on the screen. Any compromise would have to generate an intermediate "poisoned" form that did something bad to the trusted part, but sending the malicious payload would be really difficult.

It does look quite complex, but the sandboxing is not trivial either.

Google's Chromium sandbox

ncm — Wed, 19 Aug 2009 23:36:11 +0000

Couldn't another process use ptrace to perform memory allocations and similar system calls on behalf of the restricted one, as gdb does? The restricted thread can actually be stopped during the call, making it unable to do anything to interfere. The secure thread would just be a two-instruction halt loop, then.

Google's Chromium sandbox

ikm — Wed, 19 Aug 2009 22:22:31 +0000

Actually, seccomp looks like it was meant to be used exactly like this. That's why it was basically only given read and write, nothing more.

Google's Chromium sandbox

agl — Wed, 19 Aug 2009 22:03:39 +0000

I didn't consider it, but I believe that using CPU for protection (ring 1/2)
would require changes in the kernel. The beauty of seccomp is that it's been
in the kernel for several years now and is quite widely deployed.

Also, you're correct that all network IO runs in the main browser process.
This is actually a little unfortunate: it would be best to have a separate,
sandboxed process for that but, alas, that's only a wishlist item for now.

Google's Chromium sandbox

kjp — Wed, 19 Aug 2009 20:54:45 +0000

It looks like in essence, instead of trapping straight to the kernel, you are restricting the untrusted renderer to trap to a supervisor, that can then validate and trap to the kernel.

Was there consideration of using x86 ring 1 or 2 for this purpose? Is that too architecture dependent?

Anyway... still an interesting idea. The syscall table looks refreshingly small. I noticed things like socket, connect aren't in there... I take it the network IO is still running in the trusted/main process?

VEX

agl — Wed, 19 Aug 2009 19:04:26 +0000

As the text mentions, the disassembler didn't actually turn out to be all
that much code, so the motivation to use something pre-existing was less.

But also, we wouldn't want to transform all the code back and forth. By
patching the code rather than transforming it we can reuse nearly all the
.text pages and save memory.

VEX

abacus — Wed, 19 Aug 2009 17:55:04 +0000

I'm surprised that the article doesn't mention the VEX library, the core of the Valgrind tool suite. This is a library that allows to disassemble i386, x86_86 and ppc assembly code to an intermediate representation and also back to assembly. I don't doubt that the Chromium authors know about the existence of VEX and that they had good reasons to write their own disassembly code instead of using the VEX library. But I'm curious to know why.

Google's Chromium sandbox

foom — Wed, 19 Aug 2009 16:32:29 +0000

Why, for example, can an untrusted process look into my filesystem using getdents() without any checking?

Presumably because getdents takes an already-open fd, and open is sandboxed.

Google's Chromium sandbox

jake — Wed, 19 Aug 2009 16:23:16 +0000

I should have been more clear about why a thread is needed. Certain operations, memory allocation for example, cannot be done in one process on behalf of another because they don't share address space.

I don't think, but don't know for sure, that it is required to have a thread to do the disassembling. I believe that is done by the untrusted thread before it handles any user input, and before it enters seccomp mode.

jake

Qemu user space emulation

johill — Wed, 19 Aug 2009 16:19:16 +0000

Well, that would have the same verification problems when needing to talk to the host, with the extra expense of having to emulate _all_ instructions, rather than just syscalls, so much slower.

Qemu user space emulation

leonb — Wed, 19 Aug 2009 16:07:32 +0000

Naive question:
Why not run the untrusted programs under
qemu user space emulation and catch the syscalls?

- L.

Google's Chromium sandbox

johill — Wed, 19 Aug 2009 15:58:23 +0000

Hmm, the permitted list of syscalls needs comments.

Why, for example, can an untrusted process look into my filesystem using getdents() without any checking?

I think that file should come with comments as to why it is allowed, etc., because otherwise it's JUST a collection of arbitrary things, with that information at least it would be verifiable why/that it is needed.

Google's Chromium sandbox

johill — Wed, 19 Aug 2009 15:37:10 +0000

You once said 'process' rather than 'thread', I think that was an error.

Also -- I first wondered why they weren't using processes to start with to get the secure/insecure boundary more defined, but once you think about it more it doesn't seem like you could then do the disasm stuff ... might be worth mentioning that :)

Either way, interesting method, and nice article!