rwatson/chromium-capsicum

Capsicum enhancements to Google's Chromium web browser

19

15 commits

updated Feb 1, 2010

See the code

See what people are saying (1)

SourceMessageScoreDate

Software Sandboxing: The Basics (2025)

> At that time, its researchers have modified Chromium to make use of Capsicum and compared how much effort was required to make use of each sandboxing mechanism within Chromium. [..] If you’re only going to study one sandboxing mechanism in your life, it should be Capsicum. To this date, I have…

0

Sep 20, 2026

README

Chromium-Capsicum README
------------------------

Chromium-Capsicum is an adapation of Google's Chromium web browser to use
FreeBSD's Capsicum capability security primitives.  This allows renderers
(and in the future, other components) to execute in tightly-controlled
sandboxes without the need for complex access control manipulations required
when using traditional OS APIs.  This should lead to more complete and more
robust protection with significantly lower code complexity.

Capsicum is a research project at the University of Cambridge Computer
Laboratory, and sponsored by Google, Inc.  Learn more at:

  http://www.cl.cam.ac.uk/research/security/capsicum/

WARNING:

  This is a research prototype, and should be used with caution.

TODO:

- Teach process management code about process descriptors...
- ...allowing the Zygote to run cap_enable() out of EnterSandbox() rather
  than the renderer out of EnableSandbox().
- Fix closing of file descriptors when going from zygote to renderer in order
  to avoid leaking undesired rights into sandboxes.
- Encapsulate desired file descriptors for renderers in constrained
  capabilities.
- Consider switching back to SOCK_DGRAM from SOCK_SEQPACKET, as it appears
  only to be required because of limitations of the sandboxing models
  available on Linux.
- Consider re-enabling X11 SHM and adding explicit copying from the POSIX
  SHM segments.
- Determine whether chrome data packs are actually required in sandboxes,
  either as file descriptors or as memory mappings, and remove if not; they
  are currently wrapped in capabilities but perhaps are not needed at all.

Longer-term considerations:

- Use libcapability to launch sandboxes.
- Delegate font directory capabilities to fontconfig rather than using a
  proxy service.
- Extend X11 to support POSIX shared memory so that a single segment can be
  shared between {X11, browser, renderer} as is done with X11 SHM today when
  unsandboxed.
- Explore additional process sandboxing present in the Mac / Windows models
  but not supported on Linux.

Not written in Markdown, so it's shown here as plain text — view it formatted on GitHub.

Contributors

rwatson

15 commits

rwatson/chromium-capsicum

Capsicum enhancements to Google's Chromium web browser

19

15 commits

updated Feb 1, 2010

See the code

See what people are saying (1)

SourceMessageScoreDate

Software Sandboxing: The Basics (2025)

> At that time, its researchers have modified Chromium to make use of Capsicum and compared how much effort was required to make use of each sandboxing mechanism within Chromium. [..] If you’re only going to study one sandboxing mechanism in your life, it should be Capsicum. To this date, I have…

0

Sep 20, 2026

README

Chromium-Capsicum README
------------------------

Chromium-Capsicum is an adapation of Google's Chromium web browser to use
FreeBSD's Capsicum capability security primitives.  This allows renderers
(and in the future, other components) to execute in tightly-controlled
sandboxes without the need for complex access control manipulations required
when using traditional OS APIs.  This should lead to more complete and more
robust protection with significantly lower code complexity.

Capsicum is a research project at the University of Cambridge Computer
Laboratory, and sponsored by Google, Inc.  Learn more at:

  http://www.cl.cam.ac.uk/research/security/capsicum/

WARNING:

  This is a research prototype, and should be used with caution.

TODO:

- Teach process management code about process descriptors...
- ...allowing the Zygote to run cap_enable() out of EnterSandbox() rather
  than the renderer out of EnableSandbox().
- Fix closing of file descriptors when going from zygote to renderer in order
  to avoid leaking undesired rights into sandboxes.
- Encapsulate desired file descriptors for renderers in constrained
  capabilities.
- Consider switching back to SOCK_DGRAM from SOCK_SEQPACKET, as it appears
  only to be required because of limitations of the sandboxing models
  available on Linux.
- Consider re-enabling X11 SHM and adding explicit copying from the POSIX
  SHM segments.
- Determine whether chrome data packs are actually required in sandboxes,
  either as file descriptors or as memory mappings, and remove if not; they
  are currently wrapped in capabilities but perhaps are not needed at all.

Longer-term considerations:

- Use libcapability to launch sandboxes.
- Delegate font directory capabilities to fontconfig rather than using a
  proxy service.
- Extend X11 to support POSIX shared memory so that a single segment can be
  shared between {X11, browser, renderer} as is done with X11 SHM today when
  unsandboxed.
- Explore additional process sandboxing present in the Mac / Windows models
  but not supported on Linux.

Not written in Markdown, so it's shown here as plain text — view it formatted on GitHub.

Contributors

rwatson

15 commits