SecChrome: A Linux Sandbox for Chrome

SecChrome is a security-hardened launcher for Chrome or Chromium on Linux. It acts as a wrapper that leverages powerful Linux kernel features—seccomp and ptrace—to confine the browser process, limiting the impact of potential vulnerabilities.

Overview

Web browsers are complex applications and a primary target for exploitation. While browser vendors implement their own sandboxing, SecChrome provides an additional, configurable layer of defense. It enforces system call-level access control policies, ensuring that even if a vulnerability is exploited within the browser, the attacker's ability to harm the underlying system is severely restricted.

The core principle is to enforce a "least privilege" environment. The browser is only given the permissions it absolutely needs to function, and high-risk actions like arbitrary code execution, file system access, or network connections are blocked by default.

Features

• Dual Sandboxing Engines: Choose between two powerful sandboxing technologies:
  • Seccomp-notify: A high-performance kernel feature that filters syscalls with minimal overhead (typically <10%). Ideal for production environments.
  • Ptrace: A classic process tracing mechanism that requires no special privileges and offers deep inspection of syscall arguments. Ideal for development, debugging, or restricted container environments.
• Adaptive Mode Selection: Automatically chooses the best engine based on available kernel features and permissions, but can also be configured manually.
• Fine-Grained Access Control: Enforce strict rules for:
• File System Access: Control which files and directories the browser can read from or write to.
• Program Execution: Prevent the browser from executing unauthorized programs.
• System Call Filtering: Configure allow/deny rules for specific system calls to harden the sandbox at the kernel level.
• Out-of-the-Box Policies: Comes with a default security policy that is strict enough to block common attack vectors while still allowing normal browsing functions.
• Configurable and Extensible: All policies are defined in a simple config.yaml file, making it easy to customize the sandbox for your specific needs.
• Detailed Auditing: In ptrace mode, every syscall can be logged, providing full visibility into the browser's behavior for security audits and threat analysis.

Getting Started

Prerequisites

Ensure you have the following dependencies installed:

• gcc
• make
• cmake
• libseccomp-dev (or equivalent for your distribution)

An installation script is provided for convenience:

./install_dependencies.sh

Building

Once the dependencies are installed, build the project:

mkdir -p build && cd build && cmake .. && make

The launcher binary will be created at build/secure_chrome_launcher.

Configuration

Note: You should setup config at config.yaml before running the application.

1. Copy the example configuration: cp config.example.yaml config.yaml
2. Edit config.yaml:
   • Set chrome_binary to the path of your Chrome/Chromium executable.
   • Choose the security mode (seccomp_notify or ptrace_enabled).
   • Customize the file, exec, and write lists under the rules section to match your requirements.

Rule Syntax

SecChrome supports two main types of rules: Path-Based Access Rules and Syscall Rules, allowing for layered, fine-grained control.

1. Path-Based Access Rules (file, exec, write)

These rules govern access to the filesystem and program execution. They operate on a whitelist (default-deny) basis: access is denied unless a rule explicitly allows it.

Format: [action],[type],[path]

• action: allow or deny (optional, defaults to allow).
• type: The matching strategy
  • exact: Matches the path exactly.
  • prefix: Matches everything under the specified directory.
  • suffix: Matches files with the specified extension.
  • prefix_suffix: Matches files with a specific extension under a directory.
• path: The file path or pattern.

Examples:

• allow,exact,/bin/ls: Explicit exact allow.
• allow,prefix,/var/log: Recursively allow access to /var/log.
• allow,prefix_suffix,/lib/*.so: allow access to /lib/*.so.
• allow,suffix,.log: Allow any file ending in .log.

Note: Avoid broadly whitelisting your home directory (e.g. allow,prefix,/home/...) unless you fully understand the security impact. Prefer forcing Chrome profile/cache into a dedicated directory (e.g. --user-data-dir=/tmp/chrome-profile) and whitelisting only that directory. For the exec list, you will need to add the paths to your chrome executables. For example:

• allow,exact,/path/to/chrome/chrome
• allow,exact,/path/to/chrome/chrome-sandbox
• allow,exact,/path/to/chrome/chrome_crashpad_handler

2. System Call Rules (syscalls)

These rules provide low-level control over the system calls a process can make. They operate on a blacklist (default-allow) basis: all syscalls are permitted unless a rule explicitly denies them. This is necessary for compatibility with complex applications like Chrome.

Format: [action],[syscall_name]

• action: allow or deny.
• syscall_name: The name of the system call (e.g., clone, socket, setuid).

Behavior:

• A default blocklist of high-risk syscalls (e.g., ptrace, mount) is enforced.
• deny rules add to this blocklist.
• allow rules can be used to override a default block, re-enabling a specific syscall.

Note: Syscalls related to file access (open, openat) and program execution (execve, execveat) are reserved and cannot be configured here; they are managed by the Path-Based Access Rules.

Examples:

• deny,socket: Blocks the socket syscall, preventing all network connections.
• allow,ptrace: Overrides the default block on the ptrace syscall.

Usage

To start the sandboxed browser, run the secure_chrome_launcher executable from the build directory.

Command-Line Arguments

The launcher accepts several command-line arguments:

• --config=<path>: Specify the path to the config.yaml file. If not provided, it defaults to config.yaml in the current directory.
• [chrome flags]: Any arguments provided before a -- separator are passed directly to the Chrome executable.
• -- [chrome flags]: Any arguments provided after a -- separator are also passed directly to the Chrome executable.

Examples

Basic Usage:

./build/secure_chrome_launcher -headless --dump-dom https://example.com

Specifying a config file

./build/secure_chrome_launcher --config=my_config.yaml  -headless --dump-dom https://example.com

Documentation

For detailed documentation, please refer to:

• Docker Deployment Guide: Step-by-step guide for building and running SEChrome in Docker containers
• Solution Documentation: Comprehensive technical documentation covering architecture, configuration, troubleshooting, and best practices

Contributing

Contributions are welcome! Please feel free to open an issue or submit a pull request.

License

This project is licensed under the MIT License.