Re: A little RLS oversight?

On 21 July 2015 at 04:53, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost <sfrost(at)snowman(dot)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