This "Sandbox" isn't something you can actually "see" in Chrome.

It isn't really
a tool, per se. Sandboxing is just a term used to describe how measures have be
en taken to make Chrome much more secure under the hood. It's just a way of desc
ribing more secure software, to put it simply.Security
Google Chrome Puts Security in a Sandbox

Virtual Private Network. Imitation of a secluded intranet on the Web, enabling s

ecure traffic of encrypted data.

The Google Chrome browser is no longer a beta, and has been outfitted with a coa
t of security armor Google hopes will both protect users and help Chrome compete
with rival browsers.
The toughest piece of that armor involves sandboxing. In Chrome, HTML rendering
and JavaScript execution are isolated in their own class of processes. Running e
ach tab in Chrome in a sandbox allows Web applications to be launched in their o
wn browser windows without the ability to write or read files from sensitive are
as. Plug-ins are run in separate processes that communicate with the renderer.
"I think Google was very proactive in terms of what we've been doing around tryi
ng to help prevent users from being infected with malware," said Ian Fette, secu
rity product manager for Google. "On the Web browser, we're trying to do everyth
ing we can to make sure that users are not becoming affected with malware, and a
big part of that is the sandboxing technology."
Calling it a second level of defense, he said the technology is designed to prev
ent malware from persisting even if there is a flaw in the code that would lead
to the Web browser being compromised.
"It's designed to prevent malware from getting installed on the system, from bei
ng able to start again when you close the browser and restart the computer; it's
designed to help prevent malware from being able to read files on your file sys
tem it's really a defense-in-depth mechanism," Fette explained.
As noted on the Google security blog, however, there are some limitations. Since
it depends on Windows, there is the possibility of a flaw in the operating syst
em security model itself. Another issue is that some legacy file systems used on
certain computers and USB keys, such as FAT32, don't support security descripto
rs. Files on those devices can't be protected by the sandbox, according to the b
log.
In addition, if a third-party vendor configures files, registry keys and other o
bjects in a way that bypasses the access check the mechanism by which the system d
etermines whether the security descriptor of an object grants the rights request
ed to an access token it can give everyone using the machine full access.
In addition to the sandboxing, Google has outfitted Chrome with a number of secu
rity features similar to those of Internet Explorer, such as Incognito mode. Lik
e IE 8's InPrivate Browsing, Incognito mode allows users to hide their Web surfi
ng histories, and no cookies are stored beyond the lifetime of a browser window.
"Incognito mode is designed to reduce the amount of data that gets stored on you
r computer; it's not designed to provide, for instance, anonymous browsing," Fet
te said. "When you go into Incognito mode you are essentially saying, 'Everythin
g I do in this browser window, please don't record that on my computer once [I]
close off that window.'"
Chrome also takes a blacklisting approach using Google's SafeBrowsing API to pro
tect users against known malicious sites.
"I think the biggest advantage that we have is that Chrome is the first browser
built from scratch after bad guys started exploiting other browsers," opined Goo
gle Engineering Director Linus Upson. "We've had the luxury of looking at the se
curity problems other browser vendors have had, and designing around those from
the very beginning."

A virtual private network (VPN) is a computer network that is layered on top of

an underlying computer network. The private nature of a VPN means that the data
travelling over the VPN is not generally visible to, or is encapsulated from, th
e underlying network traffic. ...

Virtual Private Network. A software application that creates a secure connection

between a public computer network and a private one. At UNTHSC, Information Tec
hnology Services provides this software to enable authorized users to access res
ources on the UNTHSC network from off-campus locations.

The Chromium OS team is implementing a verified boot solution that strives to en

sure that users feel secure when logging into a Chromium OS device. Verified boo
t starts with a read-only portion of firmware, which only executes the next chun
k of boot code after verification.
Verified boot strives to ensure that all executed code comes from the Chromium O
S source tree, rather than from an attacker or corruption.
Verified boot is focused on stopping the opportunistic attacker. While verified
boot is not expected to detect every attack, the goal is to be a significant det
errent which will be improved upon iteratively.
Verification during boot is performed on-the-fly to avoid delaying system start
up. It uses stored cryptographic hashes and may be compatible with any trusted
kernel.
This document extends and expands on the Firmware Boot and Recovery document.
Verified Boot should provide a mechanism that aids the user in detecting when th
eir system is in need of recovery due to boot path changes. In particular, it sh
ould meet these requirements:
Detect non-volatile memory changes from expected state (rw firmware, EC?)
Detect file system changes relevant to system boot (kernel, init, modules, polic
ies)
Support functionality upgrades in the field
This feature is not expected to provide 100% detection of attacks. Instead, it i
s meant to raise the attack bar significantly and in a way that can be improved
upon iteratively.
It is important to note that restraining the boot path to only Chromium-project-
supplied code is not a goal. The focus is to ensure that when code is run that i
s not provided for or maintained by upstream, that the user will have the option
to immediately reset the device to a known-good state. Along these lines, there
is no dependence on remote attestation or other external authorization. Users w
ill always own their computers.
Goals of verified boot
The primary attacker in this model is an opportunistic attacker. This means that
the attacker has accessed the system using:
a remote vector, such as the Chromium-based browser or a browser plugin
a local vector, such as booting to a USB drive and changing files (but not by re
placing the write-protected firmware)
If we assume attackers access the system via a remote vector and bypass all run-
time defenses, then they will have access to modify the root partition (kernel,
modules, browser, ...), update read-write firmware, inject code into SMRAM, and
so on. In addition, the attacker can now access any data in the currently-logged
-in user's account such as locally stored media and website cookies. The attacke
r may collect passwords when typed by the user into the Chromium-based browser o
r the screenlocker.
An opportunistic local attacker will have a completely different level of access
. Access will be achieved using a USB boot drive, or other out-of-band bootable
material support by the firmware. Once the system is running the attacker's oper
ating system, she will be able to modify the root file system and encrypted user
-data blobs. She won't have any visibility into the encrypted information but ma
y copy it or modify it.
While Chromium OS does as much as possible to guard against such remote and loca
l breaches, no software system is impervious to successful attack. Therefore, it
is important that the attacker cannot continue to "own" a machine through perma
nent, local changes. To that end, on boot, the firmware and other accessible reg
ions of the system internals are verified to be in a known good state. If they a
ren't, then the firmware recovery process will be initiated (or the user can req
uest permission to proceed, which would make sense in the case of a development
install, for example).
The important factor to consider with the attackers considered above is that if
an attacker gains access via the Chromium browser, they can presumably modify th
e Chromium browser's startup (or bookmarks or server-side settings) to re-attack
the machine at next reboot. This is why it is important to be able to ensure th
at a safe recovery/reinstall is possible outside of what can be done by an attac
ker on the machine. (Obviously, this is no deterrent for a determined attacker w
illing to modify the system physically.)

The layout and structure of firmware for Chromium OS is designed for security (s
ee Verified Boot documentation), recovery and development.
All firmware will contain a recovery code path, which will restore the machine t
o it's original Chromium OS state. This recovery code path will be initiated eit
her when any chain in the boot path is not verified or when a user manually trig
gers recovery mode, likely via an explicit recovery button on the device.
Chromium OS wants to support developers as well. Developers are provided with a
means of running alternate software. In the alternate boot paths, the user is no
tified that they are not running a boot path provided as part of Chromium OS.
The boot and recovery procedures outlined will be implemented and required for b
oth x86 and ARM platforms.
This document describes the firmware boot process, including detection and recov
ery of corrupted or hacked firmware/software.
Potential problems
The firmware boot process must be able to detect the following problems and, if
possible, repair them.
Firmware
Incomplete update: An update of the firmware is interrupted. This leaves the por
tion of the firmware which was being updated in an unknown or corrupt state. For
example, if the update is interrupted after a firmware block is erased but befo
re it is reprogrammed, that block is empty.