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 (zppxedkypd6tc...@msg.df7cb.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
