Chrome version 20 introduces a new sandbox concept which regulates and filters the system calls a process is able to make, which represents a major step forward for the security of the Google browser, at least for Linux users.
In terms of security, the Linux version has, until now, been something of the ugly duckling in the Google Chrome pond, having failed to benefit from the browser’s advanced security features.
Features such as restricting hazardous plugins like Flash to a secure sandbox have been largely reserved for the Windows versions. Back in February, Google did introduce Pepper Flash for 64-bit Linux, which isolates the plugin process within a chroot environment and blocks communication with other processes. The just released Chrome 20 now adds a seccomp sandbox.
Seccomp – short for secure computing – is a security extension for the Linux kernel which restricts the system calls a thread can make. It was originally going to limit calls to just reading and writing via previously opened file handles (read(), write()) and proper termination (exit(), sigreturn()).
If a restricted thread attempts to make any other system call, the kernel terminates it directly. To make it more widely usable, the developers added the ability to have system calls sent to a special broker which checks calls against a list of permitted functions and checks any arguments before forwarding them to the system.
Chrome 20’s native 64-bit Flash plugin is, at least in the current Ubuntu 12.04, isolated within a seccomp sandbox, said Google developer Chris Evans. It complements the Pepper Flash sandbox in what Evans refers to as “double bagging.”
Because the Windows sandbox essentially relies on the integrity levels introduced in Vista and therefore permits processes to read whatever they like, the doubled-up Linux sandbox is – leaving aside external wrappers such as Blitzableiter – probably currently the safest method for executing Flash content in a browser.