On Fri, 25 Jan 2019, at 08:31, Michael Fair wrote: > In the spirit of discussing any potentially really serious drawbacks, I was > reading through the FoundationDB documents when I came across this: > > Not a security boundary > > Anyone who can connect to a FoundationDB cluster can read and write every > key in the database. There is no user-level access control. External > protections must be put into place to protect your database. > > And this StackOverflow question seems to confirm: > https://stackoverflow.com/questions/51070230/foundationdb-authentication > > Umm, so what's the expectation here? > > What gets me is that it's also a network server that "accepts" inbound > connections and they know this already... So if exposed on a public ip > address (making some site-to-site redundancy configurations easier), the > entire planet automagically has access to read/write to the entire > database... To which I think the answer is: VPNs, Firewalls, and "Don't do > that, it hurts"
Absolutely. > Which I think makes Couch a lot more complicated and less secure than it > is... > > It sounds like the result of this is "any user on any Couch node or any FDB > node can rewrite the entire FDB database", and that's assuming the > machine's firewall is configured to restrict access to the relevant IP/PORT > pairs by source address (otherwise the implication becomes anyone who can > connect). > > I saw in the recent commits for the latest version a bunch of support for > TLS, which seems to be echoed in the comment "use the mutual TLS support if > you want to run a cluster in an untrusted network"... Will a Couch cluster > also be required to create/maintain/manage the required cert files and > configuration? > > Or is there some extra magic I'm not seeing somewhere that could prevent > what seems like a 'local attacker' from maliciously wiping of the entire > keystore? > > I like being able to just install CouchDB on a laptop and use the web UI to > secure it up a bit; this seems to risk opening up access directly to the > keystore... > > Questions/Comments? > > Thanks, > Mike Security is, as Shrek would say, like an onion. I think the FDB approach is not really very different to clustered Couch today, except that the clustering layer is visibly separate instead of "just another impenetrable erlang layer". You'll still have the 127.0.0.1 loopback connection needing to be secured, on your laptop or elsewhere. Inside couchdb we have a btree module which does the dirty work of writing chunks to files, and a layer on top of that which reads and writes documents through that layer. If you bypass the couch http layer, (say by getting an erlang remote shell because you didn't secure that and somebody's on in your system) then you can write directly through to the document layer, or the db layer. I happily use this for debugging, it's very handy. Locking down ports and using separate / encrypted networks for cluster data vs user traffic, is a normal part of DB & sysadmin life. Securing access to the filesystem so you can't have arbitrary users doing r/w to the b-tree directly, or wholesale copying the db to an untrusted system. Having said that, perhaps there's a possibility for FDB to use UNIX domain sockets for a local connection? Currently I use a P2P VPN called zerotier for my (admittedly small) couchdb cluster, to secure traffic. Only those 3 instances have access to each other, all other connections are mediated through haproxy & couch's http layer. Previously I've used a "hand-crufted mesh" with spiped, which was rock solid but not quite so well suited to the dynamic architectures of today's world. FDB will need exactly the same sorts of security goop as what we have today. A+ Dave
