All known fault vectors accounted for, w/ system test per fault

[trentmc]

Abstract

BigchainDB is built on RethinkDB / MongoDB, which is tolerant to (most) crash faults but not malicious faults. The aim of this project is to identify all fault vectors, identify which ones really matter in practical scenarios, then engineer solutions for them.

Motivation

For production usage, BigchainDB needs to be resilient to all crash and malicious faults (within reason, i.e. that have high impact if they happen and high probability of happening).

Goals

• Identify & document faults
• For each fault:
  • Write a system test to expose it
  • Design & implement a solution that passes the test

Challenges

• Backend DB has no notion of a federation; we have to add that somehow
• We won't be able to be 100% thorough so this project will be followed by a 3rd party security audit (3rd party security audit, and fixes #292)

Tools to help / ideas

(WIP - spread across many places)

• Changefeed to catch deletes, etc. (Note added later: this doesn't work, because during the window when the block or whatever is gone from RethinkDB, otherwise invalid transactions [such as double spends] might be valid. The only solution is to prevent deletes [and similar bad things] before they happen.)
• Snapshotting / continuous backups (Support snapshots / archival backup #283)
• Make backend DB require signatures?
• Use a firewall or intrusion detection system that inspects IP packets, checks backend DB wire protocol messages, and block certain actions at that level. Note: this is a big project and got its own issue: Wire protocol firewall #594

Tasks

(label == topic: SEC core consensus) and (label != Project-Issue) and (not already in Project Issue #199)

• Issue Block requests to elect a new Raft leader when a leader is currently active #703 - Block requests to elect a new Raft leader when a leader is currently active
• Issue Revisit how invalid tx get decided invalid and actions taken #524 - Revisit how invalid tx get decided invalid and actions taken
• Issue Mitigate malicious nodes tampering with the changefeeds where they contribute #483 - Mitigate malicious nodes tampering with the changefeeds where they contribute
• Issue Blocks might go undecided forever #474 - Blocks might go undecided forever
• Issue What to do when a node creates another Genesis block? #444 - What to do when a node creates another Genesis block?
• Issue Handle the Case of the Unlucky Valid Transaction #424 - Handle the Case of the Unlucky Valid Transaction. Closed: wontfix
• Issue Notify other nodes when Byzantine behavior is detected #354 - Notify other nodes when Byzantine behavior is detected
• Issue Compromised node with primary replica of a shard lies and says it doesn't have it #353 - Compromised node with primary replica of a shard lies and says it doesn't have it
• Issue Fault: Atomicity of multiple updates/deletes is not guaranteed #352 - Fault: Atomicity of multiple updates/deletes is not guaranteed
• Issue Handle the case of several nodes disagreeing on the validity of a block #351 - Handle the case of several nodes disagreeing on the validity of a block
• Issue Handle blocks that have been undecided for too long #350 - Handle blocks that have been undecided for too long
• Issue Compromised node ruining blocks by including 1+ invalid tx in blocks it builds #346 - Compromised node ruining blocks by including 1+ invalid tx in blocks it builds
• Issue Handle transaction reordering attacks #345 - Handle transaction reordering attacks
• Issue Prevent replay attacks? #344 - Prevent replay attacks?
• Issue Transaction malleability of transactions containing no signatures #339 - Transaction malleability of transactions containing no signatures
• Issue Handle the case of a faulty node saying that an invalid tx is valid? #338 - Handle the case of a faulty node saying that an invalid tx is valid? Closed because Issue Notify other nodes when Byzantine behavior is detected #354 covers it.
• Issue Handle case of faulty node dropping just-received transactions #336 - Handle case of faulty node dropping just-received transactions
• Issue Denial-of-service attack from clients: mitigations & defenses #335 - Denial-of-service attack from clients: mitigations & defenses
• Issue Add assurances that a node can't modify the payload in a CREATE transaction #327 - Add assurances that a node can't modify the payload in a CREATE transaction
• Issue Bigchain.write_transaction changes the transaction passed as argument #251 - Bigchain.write_transaction changes the transaction passed as argument
• Issue How to lock down the RethinkDB "admin" account? #240 - How to lock down the RethinkDB "admin" account?
• Issue Inconsistency between vote and transaction signing #238 - Inconsistency between vote and transaction signing
• Issue Secure management of node private key #189 - Secure management of private keys
• Issue Revisit timestamps? #132 - Revisit timestamps?
• Issue Secure node-to-node communications #77 - Secure node-to-node communications
• Issue Non Deterministic assignment of transactions in S is a DoS vulnerability #20 - Non Deterministic assignment of transactions in S is a DoS vulnerability

[sohkai]

@ttmc I think we should create a milestone around this to group things, and this can be the milestone header issue (since milestones themselves really suck at presenting info).

[ttmc]

We don't really use milestones. "Project" issues with check-boxed lists of issues already have a nice UI on GitHub, with an auto-generated "3 out of 11" progress bar etc.

[sohkai]

The only thing I'm not particularly happy about with "Project" issues is that you have to keep updating the project issue if other issues are created after. It's kind of a pain to keep having to remember which issue to link it back to, and then making sure you add it there.

This is necessary when there's cross-repo projects, but for BigchainDB, I don't find it particularly helpful.

[ttmc]

I don't think it's so awful to remember the "Project" issue you're working on. It's on the wall in the conference room. If you can't get into the conference room to look, then GitHub also automatically says when two issues are linked via mentions.