Chromium Blog: A new approach to browser security: the Google Chrome Sandbox

Chromium Blog

News and developments from the open source browser project

A new approach to browser security: the Google Chrome Sandbox

jueves, 2 de octubre de 2008

Building a secure browser is a top priority for the Chromium team; it's why we spend a lot of time and effort keeping our code secure. But as you can imagine, code perfection is something almost impossible to achieve for a project of this size and complexity. To make things worse, a browser spends most of its time handling and executing untrusted and potentially malicious input data. In the event that something goes wrong, the team has developed a sandbox to help thwart any exploit in two of the most popular vectors of attack against browsers: HTML Rendering and JavaScript execution.
In a nutshell, a sandbox is security mechanism used to run an application in a restricted environment. If an attacker is able to exploit the browser in a way that lets him run arbitrary code on the machine, the sandbox would help prevent this code from causing damage to the system. The sandbox would also help prevent this exploit from modifying and even reading your files or any information on the system.
We are very excited to be able to launch Google Chrome with the sandbox enabled on all the platforms we currently support. Even though the sandbox in Google Chrome uses some of the new security features on Windows Vista, it is fully compatible with Windows XP.
What part of chromium is sandboxed?
Google Chrome's multi process architecture allows for a lot of flexibility in the way we do security. The entire HTML rendering and JavaScript execution is isolated to its own class of processes; the renderers. These are the ones that live in the sandbox. We expect to work in the near future with the plug-in vendors to securely sandbox them as well.
How does the sandbox work?
The sandbox uses the security features of Windows extensively; it does not reinvent any security model.
To understand how it works, one needs a basic understanding of the Windows security model. With this model all processes have an access token. This access token is like an ID card, it contains information about the owner of the process, the list of groups that it belongs to and a list of privileges. Each process has its own token, and the system uses it to deny or grant access to resources.
These resources are called securable objects. They are securable because they are associated with an access control list, or security descriptor. It contains the security settings of the object. The list of all the users and groups having access to the resource, and what kind of access they have (read, write, execute, etc) can be found there. Files, registry keys, mutexes, pipes, events, semaphores are examples of securable objects.
The access check is the mechanism by which the system determines whether the security descriptor of an object grants the rights requested to an access token. It is performed every time a process tries to acquire a securable object.
The process access token is almost entirely customizable. It's possible to remove privileges and disable some groups. This is exactly what the sandbox does.
Before launching the renderer process we modify its token to remove all privileges and disable all groups. We then convert the token to a restricted token. A restricted token is like a normal token, but the access checks are performed twice, the first time with the normal information in the token, and the second one using a secondary list of groups. Both access checks have to succeed for the resources to be granted to the process. Google Chrome sets the secondary list of groups to contain only one item, the NULL user. Since this user is never given permissions to any objects, all access checks performed with the access token of the renderer process fail, making this process useless to an attacker.
Of course, not all resources on Windows follow this security model. The keyboard, the mouse, the screen and some user objects, like cursors, icons and windows are examples of resources that don't have security descriptors. There is no access check performed when trying to access them. To prevent the renderer from accessing those, the sandbox uses a combination of Job Objects and alternate desktops. A job object is used to apply some restrictions on a group of processes. Some of the restrictions we apply on the renderer process include accessing windows created outside the job, reading or writing to the clipboard, and exiting Windows. We also used an alternate desktop to prevent the renderer from seeing the screen (screen scrapping) or eavesdropping on the keyboard and mouse (key logging). Alternate desktops are commonly used for security. For example, on Windows, the login screen is on another desktop. It ensures that your password can't be stolen by applications running on your normal desktop.
What are the limitations?
As we said earlier, the sandbox itself is not a new security model; it relies on Windows to achieve its security. Therefore, it is impossible for us to prevent against a flaw in the OS security model itself. In addition, some legacy file systems, like FAT32, used on certain computers and USB keys don't support security descriptors. Files on these devices can't be protected by the sandbox. Finally, some third party vendors mistakenly configure files, registry keys and other objects in a way that bypasses the access check, giving everyone on the machine full access on them. Unfortunately, it's impossible for the sandbox to protect most of these misconfigured resources.
To conclude, it is important to mention that this sandbox was designed to be generic. It is not tied to Google Chrome. It can easily be used by any other projects with a compatible multi-process architecture. You can find more information about the sandbox in the design doc, and we will post here again about the details of our token manipulation and our policy framework to configure the level of security of the sandbox.
We hope you will feel safe browsing the web using Google Chrome, and we are looking forward to your feedback and code contribution!
Posted by Nicolas Sylvain, Software Engineer

Google

Etiquetas

$200K 1
10th birthday 4
abusive ads 1
abusive notifications 2
accessibility 3
ad blockers 1
ad blocking 2
advanced capabilities 1
android 2
anti abuse 1
anti-deception 1
background periodic sync 1
badging 1
benchmarks 1
beta 83
better ads standards 1
billing 1
birthday 4
blink 2
browser 2
browser interoperability 1
bundles 1
capabilities 6
capable web 1
cds 1
cds18 2
cds2018 1
chrome 35
chrome 81 1
chrome 83 2
chrome 84 2
chrome ads 1
chrome apps 5
Chrome dev 1
chrome dev summit 1
chrome dev summit 2018 1
chrome dev summit 2019 1
chrome developer 1
Chrome Developer Center 1
chrome developer summit 1
chrome devtools 1
Chrome extension 1
chrome extensions 3
Chrome Frame 1
Chrome lite 1
Chrome on Android 2
chrome on ios 1
Chrome on Mac 1
Chrome OS 1
chrome privacy 4
chrome releases 1
chrome security 10
chrome web store 32
chromedevtools 1
chromeframe 3
chromeos 4
chromeos.dev 1
chromium 9
cloud print 1
coalition 1
coalition for better ads 1
contact picker 1
content indexing 1
cookies 1
core web vitals 2
csrf 1
css 1
cumulative layout shift 1
custom tabs 1
dart 8
dashboard 1
Data Saver 3
Data saver desktop extension 1
day 2 1
deceptive installation 1
declarative net request api 1
design 2
developer dashboard 1
Developer Program Policy 2
developer website 1
devtools 13
digital event 1
discoverability 1
DNS-over-HTTPS 4
DoH 4
emoji 1
emscriptem 1
enterprise 1
extensions 27
Fast badging 1
faster web 1
features 1
feedback 2
field data 1
first input delay 1
Follow 1
fonts 1
form controls 1
frameworks 1
fugu 2
fund 1
funding 1
gdd 1
google earth 1
google event 1
google io 2019 1
google web developer 1
googlechrome 12
harmful ads 1
html5 11
HTTP/3 1
HTTPS 4
iframes 1
images 1
incognito 1
insecure forms 1
intent to explain 1
ios 1
ios Chrome 1
issue tracker 3
jank 1
javascript 5
lab data 1
labelling 1
largest contentful paint 1
launch 1
lazy-loading 1
lighthouse 2
linux 2
Lite Mode 2
Lite pages 1
loading interventions 1
loading optimizations 1
lock icon 1
long-tail 1
mac 1
manifest v3 2
metrics 2
microsoft edge 1
mixed forms 1
mobile 2
na 1
native client 8
native file system 1
New Features 5
notifications 1
octane 1
open web 4
origin trials 2
pagespeed insights 1
pagespeedinsights 1
passwords 1
payment handler 1
payment request 1
payments 2
performance 20
performance tools 1
permission UI 1
permissions 1
play store 1
portals 3
prefetching 1
privacy 2
privacy sandbox 4
private prefetch proxy 1
profile guided optimization 1
progressive web apps 2
Project Strobe 1
protection 1
pwa 1
QUIC 1
quieter permissions 1
releases 3
removals 1
rlz 1
root program 1
safe browsing 2
Secure DNS 2
security 36
site isolation 1
slow loading 1
sms receiver 1
spam policy 1
spdy 2
spectre 1
speed 4
ssl 2
store listing 1
strobe 2
subscription pages 1
suspicious site reporter extension 1
TCP 1
the fast and the curious 23
TLS 1
tools 1
tracing 1
transparency 1
trusted web activities 1
twa 2
user agent string 1
user data policy 1
v8 6
video 2
wasm 1
web 1
web apps 1
web assembly 2
web developers 1
web intents 1
web packaging 1
web payments 1
web platform 1
web request api 1
web vitals 1
web.dev 1
web.dev live 1
webapi 1
webassembly 1
webaudio 3
webgl 7
webkit 5
WebM 1
webmaster 1
webp 5
webrtc 6
websockets 5
webtiming 1
writable-files 1
yerba beuna center for the arts 1

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms

Chromium Blog

A new approach to browser security: the Google Chrome Sandbox

Etiquetas

Archive

Feed