On 21 July 2015 at 04:53, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost <sfr...@snowman.net> wrote: >> We need to be careful to avoid the slippery slope of trying to prevent >> all covert channels, which has been extensively discussed previously.
I think this is more serious than the covert channel leaks discussed before, since most_common_vals explicitly reveals values from the table, making it an overt leak, albeit of a small portion of the table's values. > Looking at that I am not seeing any straight-forward way to resolve > this issue except by hardening pg_stats by having an additional filter > of this type so as a non-owner of a relation cannot see the stats of > this table directly when RLS is enabled: > c.relrowsecurity = false OR c.relowner = current_user::regrole::oid > Attached is a patch doing that (/me now hides, expecting to receive > laser shots because of the use of current_user on a system view). > Thoughts? Hmm, I think it probably ought to do more, based on whether or not RLS is being bypassed or in force-mode -- see the first few checks in get_row_security_policies(). Perhaps a new SQL-callable function exposing those checks and calling check_enable_rls(). It's probably still worth including the "c.relrowsecurity = false" check in SQL to save calling the function for the majority of tables that don't have RLS. There's another issue here though -- just adding filters to the pg_stats view won't prevent a determined user from seeing the contents of the underlying table. For that, the view needs to have the security_barrier property. Arguably the fact that pg_stats isn't a security barrier view is a long-standing information leak allowing users to see values from tables for which they don't have any permissions. Is anyone concerned about that? Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
