Hi, On 2021-05-27 10:57:24 -0400, Bruce Momjian wrote: > On Wed, May 26, 2021 at 04:26:01PM -0700, Andres Freund wrote: > > I suspect that if we try to not disclose data if an attacker has write > > access, this still leaves us with issues around nonce reuse, unless we > > also employ integrity measures. Particularly due to CTR mode, which > > makes it easy to manipulate individual parts of the encrypted page > > without causing the decrypted page to be invalid. E.g. the attacker can > > just update pd_upper on the page by a small offset, and suddenly the > > replay will insert the tuple at a slightly shifted offset - which then > > seems to leak enough data to actually analyze things? > > Yes, I don't think protecting from write access is a realistic goal at > this point, and frankly ever. I think write access protection needs > all-cluster-file encryption. This is documented: > > > https://github.com/postgres/postgres/compare/master..bmomjian:_cfe-01-doc.patch > > Cluster file encryption does not protect against unauthorized > file system writes. Such writes can allow data decryption if > used to weaken the system's security and the weakened system is > later supplied with the externally-stored cluster encryption key. > This also does not always detect if users with write access remove > or modify database files. > > If this needs more text, let me know.
Well, it's one thing to say that it's not a complete protection, and another that a few byte sized writes to a single page are sufficient to get access to encrypted data. And "all-cluster-file" encryption won't help against the type of scenario I outlined. > > https://github.com/bmomjian/postgres/commit/7b43d37a5edb91c29ab6b4bb00def05def502c33#diff-0dcb5b2f36c573e2a7787994690b8fe585001591105f78e58ae3accec8f998e0R92 > > /* > > * Check if the page has a special size == GISTPageOpaqueData, a valid > > * GIST_PAGE_ID, no invalid GiST flag bits are set, and a valid LSN. > > This > > * is true for all GiST pages, and perhaps a few pages that are not. > > The > > * only downside of guessing wrong is that we might not update the LSN > > for > > * some non-permanent relation page changes, and therefore reuse the IV, > > * which seems acceptable. > > */ > > > > Huh? > > Are you asking about this C commention in relation to the discussion > above, or is it an independent question? Are asking what it means? The comment is blithely waving away a fundamental no-no (reusing nonces) when using CTR mode as "acceptable". Greetings, Andres Freund