Security guidelines for closed-source components

Closed-source third-party components pose particular challenges to ensuring the overall security and stability of ChromeOS since they:

• are hard to inspect for security and robustness.
• are compiled with a toolchain that we don't control.
  • toolchain-based hardening varies with vendor
  • availability & usage of tools like asan/msan/tsan is inconsistent
• make vulnerability response more complex.
  • dependent on responsiveness of vendor
  • requires much more coordination even in the ideal case

For these reasons binary third-party components should be avoided as far as possible.

If there are strong business reasons to include the component, then it must be strictly isolated. It should:

• run with minimal privileges, and
• be walled off from untrusted input.

In addition, we must require the vendor to use some means of ensuring robustness. For example:

• Fuzzing
• Static analysis
• Code audits

The vendor should be asked to document their development practices, with emphasis on:

• continuous testing, fuzzing
• security practices during design and development
• security validation of the finished product
• incident response (SLO, notifications, etc.)
• proactive hardening

The first party code that interacts with the binary component must strictly verify its inputs and outputs, and fuzzing is strongly recommended.

For firmware binaries, the sandboxing should ideally take the form of hardware mechanisms that make it impossible for compromised firmware to affect the rest of the system (eg. IOMMU).