On 2/28/19 11:03 AM, Joshua Brindle wrote: > On Thu, Feb 28, 2019 at 10:49 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Joshua Brindle <joshua.brin...@crunchydata.com> writes: >> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas <robertmh...@gmail.com> wrote: >> >> So... you're just going to replace ALL error messages of any kind with >> >> "ERROR: missing error text" when this option is enabled? That sounds >> >> unusable. I mean if I'm reading it right this would get not only >> >> messages from SQL-callable functions but also things like "deadlock >> >> detected" and "could not read block %u in file %s" and "database is >> >> not accepting commands to avoid wraparound data loss in database with >> >> OID %u". You can't even shut it off conveniently, because the way >> >> > This makes complete sense to me. The client side of a client/server >> > protocol doesn't have any way to fix 'could not read block %u in file >> > %s', the client doesn't need that kind of detailed information about a >> > server, and in fact that information could be security sensitive. >> >> I agree with Robert that this idea is a nonstarter. Not only is it >> a complete disaster from a usability standpoint, but *it does not >> fix the problem*. The mere fact that an error occurred, or didn't, >> is already an information leak. Sure, you can only extract one bit >> per query that way, but a slow leak is still a leak. See the Spectre >> vulnerability for a pretty exact parallel. > > How is leakproof defined WRT Postgres? Generally speaking a 1 bit > error path would be considered a covert channel on most systems and > are relatively slow even compared to e.g., timing channels.
Yes, I am pretty sure there are plenty of very security conscious environments that would be willing to make this tradeoff in order to get reliable RLS performance. > Redacting error information, outside of the global leakproof setting, > seems useful to prevent data leakage to a client on another system, > such as Robert's example above "could not read block %u in file %s". True > Although, and Joe may hate me for saying this, I think only the > non-constants should be redacted to keep some level of usability for > regular SQL errors. Maybe system errors like the above should be > removed from client messages in general. I started down this path and it looked fragile. I guess if there is generally enough support to think this might be viable I could open up that door again, but I don't want to waste time if the approach is really a non-starter as stated upthread :-/. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature