Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem?
Yes and no. They discuss this on page 2.
> An oft-cited threat to DB security is disk theft, i.e., theft of persistent storage [2,16,20,32,37,42,47,50]. Full-disk encryption (FDE) can mitigate this threat, but EDBs aim to protect data even in the absence of FDE. Without FDE, this attack yields the persistent OS and DB state, but not any volatile state.
Even with FDE, an attacker who can do some sort of software exploitation can still grab all the data they need out of the filesystem.
It's worth reading the whole paper if you're interested in the topic. It's only 6.5 pages of content, and it's written in a way that makes the technical stuff pretty accessible to a general CS audience.
> Any good recommendations for running Postgres transparently as a fully encrypted database (not just on a table by table basis)?
Hard to tell what you're asking here. You can't just encrypt all the data inside Postgres, or it won't be able to perform queries anymore. You can read the CryptDB paper cited here to learn about the trade-offs that some encrypted databases have made in order to re-enable queries on encrypted data. In a nutshell, they use much weaker encryption that reveals a lot more information about the contents of the DB. Then read up on the attacks also cited here to see why that's generally a bad idea.
(Full disclosure: I'm an author of one of the attack papers.)
Another way in which disks end up in places where they shouldn't be is faulty decommissioning processes.
This might help as a primer for this type of question: https://security.stackexchange.com/questions/16939/is-it-gen...
I haven't heard that they were successful.
> I haven't heard that they were successful.
Isn't it rather trivial to prove that a database can't be secure if the OS or hypervisor is compromised? (I mean, how could it be, since the OS/hypervisor can read/write all memory, pause execution, alter execution, etc. by its very nature?)
I feel it's not constructive to claim that solutions that provide intermediate security are useless; schemes that provide strong security (eg. ORAM based schemes) are far from practicality, and so these intermediate security solutions are the best we've got.
Respectfully, I find this "more secure stuff is slow so we have to live with what we've got" argument to be specious. There simply is no evidence that a fast encrypted database must also provide very weak confidentiality guarantees.
Either way, as I said earlier, it's a question of threat models. Most cloud users trust Google and Amazon. These companies also have strong intrusion detection capabilities, so with non-negligible probability an outside attacker would be detected within a reasonable amount of time. In such a scenario, it is better to have some protection than none at all.
I will only say that I don't think this problem (strong security + performance) has been on the minds of very many people for very long, and this work is really still in its infancy.
EDIT: The fundamental problem is that trusted hardware doesn't hide the access pattern by itself. Trusted hardware can be used to hide some kinds of access patterns, but it's highly nontrivial and has only been demonstrated in some limited settings. For example, there was a paper at NSDI this year called "Opaque" which showed how to use SGX to hide access patterns for some kinds of Spark queries.
I presume it's relying on the paging behavior of SGX? (Either page faults or dirty bits).
Or are you referring to one of your personal passwords ending up on Pastebin? Use unique passwords, set up SSH keys, and set "PasswordAuthentication no" in your SSHD config.
Doesn't this go without saying? Seems kind of ridiculous to try to protect against that attack vector at least on today's hardware.
Defending sensitive data if the DB process itself is compromised, again, seems pretty difficult. That was the original goal of the academic proposals like CryptDB or Cipherbase - defense even against a fully malicious database server.