The doc mentions that there’s no security boundary or user-level access control.
How is this handled in practice? Can it be in the layers?
A layer could provide security if it is designed as a service which is deployed in between your clients and the actual FDB cluster.
This is properly the concern of layers, which have an actual data model to apply access control on!
The TLS plugin can provide authentication for access to a FoundationDB cluster as a whole.
FoundationDB is written in a memory unsafe language and has not been carefully audited for security bugs. So frankly it would be wisest to assume that any client that can connect to an fdbserver (and pass TLS authentication, if applicable) can exploit some bug in fdbserver and operate with its privileges! Again, layers are likely written in safer languages and are a much better place to put the security boundary around your database.
2 Likes
That makes sense. Thanks!
Won’t simulations catch such bugs?
Won’t simulations catch such bugs?
In short, no.
-
Our simulation tests currently model many types of failures and errors, but not attacks (“Byzantine faults”). There are no malicious clients sending invalid messages to the servers in simulation.
-
Attacks, unlike failures, are not random, but maliciously crafted. So the usual reason that randomized testing, despite being able to cover only an infinitesimal fraction of the search space, can usually find bugs before they occur in reality, doesn’t apply. Looking for security bugs calls for a more sophisticated search strategy.
-
When using unsound methods (such as testing) to find security flaws, attackers have a fundamental advantage over defenders. The attacker only needs to find a single exploitable bug before the defender, while the defender needs to find every such bug before the attacker. This asymmetry makes it unwise to depend on any form of testing as the primary line of defense against security flaws.
2 Likes