Chrompartments: Hybrid Compartmentalisation for Web Browsers
Lead Research Organisation:
King's College London
Department Name: Informatics
Abstract
The Chrompartments project will explore hybrid compartmentalisation for web
browsers using Chrome as a concrete example. Browsers are systemically important
but present a large attack surface due to their scale and complexity: they are a
magnet for attackers with frequent published attacks.
Chrompartments will use CHERI to split browsers into mutually distrusting
compartments, making them more resilient and performant. We will use Chrome (in
the form of its open-source variant Chromium) as the vehicle for our
experimentation because it is the most widely used browser and it is already
partially compartmentalised in a way that we can build upon. Chrome tries when
possible to split itself into process-based compartments (roughly speaking: 1
process per tab; and some core components such as graphics are split into
separate processes). However, this model is heavyweight: OS processes consume
considerable resources and many devices (particularly phones) quickly hit their
process limits, forcing the browser to merge multiple tabs in a single process;
and communication between processes is painfully slow. Some security-critical
components (e.g. V8, Chrome's JavaScript engine) would ideally be split out too,
but resource and performance constraints make this impractical.
We will use CHERI's "hybrid mode" (i.e. where both traditional width pointers
can be used alongside capabilities) to split Chrome into process-like
compartments. Most code will use traditional width pointers and will be boxed
into compartments; pure capabilities will allow us to emulate various forms of
inter-compartment communication. We hypothesise that this will lead to greater
practical security, and require fewer changes, than the ideal
pure-capability-based compartmentalisation.
Our overall aim is thus first to replace Chrome's process-based model with CHERI
compartments, and then break those crude compartments into finer-grained
compartments, enhancing security without significantly affecting performance. As
well as significant engineering, there is also important research: processes
give some guarantees (e.g. against some side-channel attacks) that CHERI
compartments do not currently give. We will explore these guarantees and
replicate them for CHERI compartments where their existence is necessary for
browser security.
After converting process-based isolation to CHERI compartmentalisation,
Chrompartments will operate in two strands: V8, the JavaScript engine; and the
graphics stack. Both strands contain significant challenges: for example, the
graphics stack is currently contained within a single process no matter how many
sites are using it. Understanding the right compartmentalisation points will be
critical to Chrompartments' success and lead to a much greater understanding of
how to use CHERI on large-scale systems.
browsers using Chrome as a concrete example. Browsers are systemically important
but present a large attack surface due to their scale and complexity: they are a
magnet for attackers with frequent published attacks.
Chrompartments will use CHERI to split browsers into mutually distrusting
compartments, making them more resilient and performant. We will use Chrome (in
the form of its open-source variant Chromium) as the vehicle for our
experimentation because it is the most widely used browser and it is already
partially compartmentalised in a way that we can build upon. Chrome tries when
possible to split itself into process-based compartments (roughly speaking: 1
process per tab; and some core components such as graphics are split into
separate processes). However, this model is heavyweight: OS processes consume
considerable resources and many devices (particularly phones) quickly hit their
process limits, forcing the browser to merge multiple tabs in a single process;
and communication between processes is painfully slow. Some security-critical
components (e.g. V8, Chrome's JavaScript engine) would ideally be split out too,
but resource and performance constraints make this impractical.
We will use CHERI's "hybrid mode" (i.e. where both traditional width pointers
can be used alongside capabilities) to split Chrome into process-like
compartments. Most code will use traditional width pointers and will be boxed
into compartments; pure capabilities will allow us to emulate various forms of
inter-compartment communication. We hypothesise that this will lead to greater
practical security, and require fewer changes, than the ideal
pure-capability-based compartmentalisation.
Our overall aim is thus first to replace Chrome's process-based model with CHERI
compartments, and then break those crude compartments into finer-grained
compartments, enhancing security without significantly affecting performance. As
well as significant engineering, there is also important research: processes
give some guarantees (e.g. against some side-channel attacks) that CHERI
compartments do not currently give. We will explore these guarantees and
replicate them for CHERI compartments where their existence is necessary for
browser security.
After converting process-based isolation to CHERI compartmentalisation,
Chrompartments will operate in two strands: V8, the JavaScript engine; and the
graphics stack. Both strands contain significant challenges: for example, the
graphics stack is currently contained within a single process no matter how many
sites are using it. Understanding the right compartmentalisation points will be
critical to Chrompartments' success and lead to a much greater understanding of
how to use CHERI on large-scale systems.