How Google Chrome Browser Works
In the article Chrome Browser Security @STEPHANIE CRAWFORD mentioned, Google has leveraged its power as a search engine by creating its Safe Browsing technology which will automatically warn you if Chrome detects that a site you’re visiting contains malware or phishing.
Chrome deploys this security measure through a unique security feature termed as Sandboxing. Sandboxing implies, separating each process out into independent spaces to see how they function individually. Chrome handles its workload as a series of multiple processes rather than as part of one large browser process. Each time you open a Web page, Chrome launches one or more new processes to run the scripts on that page. Also, each Chrome extension and app runs in its own process. Chrome implements sandboxing through its multi-process architecture. The security advantage in sandboxing comes with Chrome being able to control the access token for each process. These access token for a process allows that process access to important information about your system, like its files and registry keys. Chrome intercepts each access token from the processes launched from the browser, and it modifies that token to limit its access to that information. So, Chrome’s sandboxing helps block web pages that try to install malware, capture your personal information or obtain data from your hard drive. The drawback of sandboxing is that, it can’t catch everything. A sandboxed process might still be able to access less secure file systems. It’s also likely to miss protecting registry keys and files managed by third party software, like a game or chat program that isn’t native to the system.
WebDriver driven Chrome
While initiating a WebDriver controled Chrome Browsing Context using Selenium recently we had been advocating to use a certain command line argument:
--no-sandbox: Disables the sandbox for all process types that are normally sandboxed.
See:
- WebDriverException: unknown error: DevToolsActivePort file doesn’t exist while trying to initiate Chrome Browser
- How to configure ChromeDriver to initiate Chrome browser in Headless mode through Selenium?
- unknown error: session deleted because of page crash from unknown error: cannot determine loading status from tab crashed with ChromeDriver Selenium
No Sandbox
There are a couple of more Sandbox related flags available which enables the sandboxed processes to run without a job object assigned to them. This flag is required to allow Chrome to run in RemoteApps or Citrix. This flag can reduce the security of the sandboxed processes and allow them to do certain API calls like shut down Windows or access the clipboard. Also we lose the chance to kill some processes until the outer job that owns them finishes.
- –allow-no-sandbox-job: Disables usage of sandbox job.
- –allow-sandbox-debugging: Allows debugging of sandboxed processes.
- –disable-gpu-sandbox: Disables the GPU process sandbox.
- –disable-namespace-sandbox: Disables usage of the namespace sandbox.
- –disable-seccomp-filter-sandbox: Disable the seccomp filter sandbox (seccomp-bpf) (Linux only).
- –disable-setuid-sandbox: Disable the setuid sandbox (Linux only).
- –disable-win32k-lockdown: Disables the Win32K process mitigation policy for child processes.
- –enable-audio-service-sandbox: enable the audio service sandbox.
- –gpu-sandbox-allow-sysv-shm: Allows shmat() system call in the GPU sandbox.
- –gpu-sandbox-failures-fatal: Makes GPU sandbox failures fatal.
- –no-sandbox-and-elevated: Disables the sandbox and gives the process elevated privileges (Windows only).
Sandbox
Sandbox leverages the OS-provided security to allow code execution that cannot make persistent changes to the computer or access information that is confidential. The architecture and exact assurances that the sandbox provides are dependent on the operating system.
- windows implementation principles:
- Do not re-invent the wheel: It is tempting to extend the os kernel with a better security model. Don’t. Let the operating system apply its security to the objects it controls. On the other hand, it is just okay to create application-level objects (abstractions) that have a custom security model.
- Principle of least privilege: This should be applied both to the sandboxed code and to the code that controls the sandbox. In other words, the sandbox should work even if the user cannot elevate to super-user.
- Assume sandboxed code is malicious code: For threat-modeling purposes, we consider the sandbox compromised (that is, running malicious code) once the execution path reaches past a few early calls in the main() function. In practice, it could happen as soon as the first external input is accepted, or right before the main loop is entered.
- Be nimble: Non-malicious code does not try to access resources it cannot obtain. In this case the sandbox should impose near-zero performance impact. It’s ok to have performance penalties for exceptional cases when a sensitive resource needs to be touched once in a controlled manner. This is usually the case if the OS security is used properly.
- Emulation is not security: Emulation and virtual machine solutions do not by themselves provide security. The sandbox should not rely on code emulation, code translation, or patching to provide security.
- linux implementation
- macos implementation