Re: Restrict EXPLAIN (ANALYZE) for RLS and security_barrier views

On Mon, 2024-05-06 at 16:46 +0200, Laurenz Albe wrote:
> Currently, it is pretty easy to subvert the restrictions imposed
> by row-level security and security_barrier views.  All you have to
> to is use EXPLAIN (ANALYZE) and see how many rows were filtered
> out by the RLS policy or the view condition.
>
> This is not considered a security bug (I asked), but I still think
> it should be fixed.
>
> My idea is to forbid EXPLAIN (ANALYZE) for ordinary users whenever
> a statement uses either of these features.  But restricting it to
> superusers would be too restrictive (with a superuser, you can never
> observe RLS, since superusers are exempt) and it would also be
> dangerous (you shouldn't perform DML on untrusted tables as superuser).
>
> So I thought we could restrict the use of EXPLAIN (ANALYZE) in these
> situations to the members of a predefined role.  That could be a new
> predefined role, but I think it might as well be "pg_read_all_stats",
> since that role allows you to view sensitive data like the MCV in
> pg_statistic, and EXPLAIN (ANALYZE) can be seen as provideing executor
> statistics.

After a discussion on the pgsql-security list (ZppxEDkyPd6tCSiq(at)msg(dot)df7cb(dot)de),
I am going to mark this patch as rejected.

The gist of that discussion was that even without EXPLAIN (ANALYZE),
it is easy enough for a determined attacker who can run arbitrary
SQL to subvert row-level security.
Therefore, restricting EXPLAIN (ANALYZE) will do more harm than good,
since it will make analyzing query performance harder without a
real security gain.

Yours,
Laurenz Albe