On Fri, Jun 22, 2018 at 05:31:44AM +0000, Tsunakawa, Takayuki wrote:
> From: Nico Williams [mailto:nico@cryptonector.com]
> > Let's start with a set of threat models then. I'll go first:
>
> Thank you so much for summarizing the current situation. I'd
> appreciate it if you could write this on the PostgreSQL wiki, when the
> discussion has settled somehow.
Sure, that's a good idea.
> > - local adversaries (addressed by standard OS user process isolation)
>
> Does this also mean that we don't have to worry about the following?
>
> * unencrypted data in the server process memory and core files
> * passwords in .pgpass and recovery.conf (someone familiar with PCI
> DSS audit said this is a problem)
> * user data in server logs
Short of using things like Intel SGX or homomorphic encryption, I don't
think we can do anything about plaintext in memory -- at some point it
has to be there, therefore it is as vulnerable as the host OS makes it.
Users can always run only the one postgres instance and nothing else
(and no other non-admin users) on the host to reduce local attack
surface to zero.
So, yes, I think this flavor of local vulnerability should be out of
scope for PG.
> > One shortcoming of relying on OS functionality for protection against
> > malicious storage is that not all OSes may provide such functionality.
> > This could be an argument for implementing full, transparent encryption
> > for an entire DB in the postgres server. Not a very compelling
> > argument, but that's just my opinion -- reasonable people could differ
> > on this.
>
> Yes, this is one reason I developed TDE in our product. And
> in-database encryption allows optimization by encrypting only user
> data.
I understand this motivation. I wouldn't reject this out of hand, even
though I'm not exactly interested either.
Can you keep the impact on the codebase isolated and limited, and the
performance impact when disabled to zero?
> > So I think for (3) the best answer is to just not have that problem:
> > just reduce and audit admin access.
> >
> > Still, if anyone wants to cover (3), I argue that PG gives you
> > everything you need right now: FDW and pgcrypto. Just build a
> > solution where you have a PG server proxy that acts as a smart
> > client to untrusted servers:
>
> Does sepgsql help?
Any functionality in PG that allows DBAs to manage storage, sessions,
..., without having to see table data will help. It doesn't ahve to be
tied to trusted OS functionality.
I've not looked at SEP [0] so I don't know if it helps. I would prefer
that PG simply have native functionality to allow this sort of
separation -- as I'm not a DBA, I don't really know if PG has this.
[0] https://wiki.postgresql.org/wiki/SEPostgreSQL_SELinux_Overview
> Should a malfunctioning or buggy application be considered as as a
> threat? That's what sql_firewall extension addresses.
I suppose so, yes.
Nico
--
