Run the scanner in an isolated environment

[teor2345]

Motivation

Zebra's scanner currently runs asynchronously in the same process. This prevents some timing attacks, but still leaves the private keys vulnerable to memory unsafety and remote code execution.

It could also result in tight binding of the scanner with Zebra's internal APIs, making it difficult to change.

Alternatives

There are a range of isolation options we can use for the scanner.

Here are some alternatives and a quick security analysis for each:

• Run scanner asynchronously, don't block verification waiting for the scanner results
  • Prevents almost all timing attacks except for CPU exhaustion.
• Use a separate database for the scanner
  • Allows the database to be protected with strict filesystem permissions.
• security: Files created by Zebra can be read by any user on the same machine #7807
  • Actually sets those stricter permissions on the database.
• security: Run the scanner it is own tokio executor, and use low-priority threads to avoid timing attacks #8043
  • Prevents CPU exhaustion timing attacks, and accidentally blocking the shared tokio executor.
• Run the scanner in a separate process
  • Prevents timing attacks.
  • Needs low-priority threads to prevent CPU exhaustion.
  • Prevents memory safety attacks
  • Needs RPCs to get non-finalized blocks, or a shared finalized and non-finalized database on disk.
• Store scanner viewing keys in a separate file, and give them more restrictive file permissions #8048
  • Allows key files to be protected with strict filesystem permissions.
• Make key files and results database owned by a separate users
  • Allows full filesystem isolation.
  • Requires a separate process.