Re: Information of pg_stat_ssl visible to all users

* Josh Berkus (josh(at)agliodbs(dot)com) wrote:
> On 07/07/2015 09:06 AM, Magnus Hagander wrote:
> >
> > To make it accessible to monitoring systems that don't run as superuser
> > (which should be most monitoring systems, but we have other cases making
> > that hard as has already been mentioned upthread).
> >
> > I'm having a hard time trying to figure out a consensus in this thread.
> > I think there are slightly more arguments for limiting the access though.
> >
> > The question then is, if we want to hide everything, do we care about
> > doing the "NULL dance", or should we just throw an error for
> > non-superusers trying to access it?
>
> I'm going to vote against blocking the entire view for non-superusers.
> One of the things people will want to monitor is "are all connection
> from subnet X using SSL?" which is most easily answered by joining
> pg_stat_activity and pg_stat_ssl.
>
> If we force users to use superuser privs to find this out, then we're
> encouraging them to run monitoring as superuser, which is something we
> want to get *away* from.

I agree with all of this, but I'm worried that if we make it available
now then we may not be able to hide it later, even once we have the
monitoring role defined, because of backwards compatibility concerns.

If we aren't worried about that, then perhaps we can leave it less
strict for 9.5 and then make it stricter for 9.6.

> I'd be OK with concealing some columns:
>
> postgres=# select * from pg_stat_ssl;
> pid | ssl | version | cipher | bits | compression
> | clientdn
> -----+-----+---------+-----------------------------+------+-------------+----------
> 37 | t | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384 | 256 | f |
>
> I can see NULLifying cipher and DN columns. The other columns, it's
> hard to imagine what use an attacker could put them to that they
> wouldn't be able to find out the same information easily using other routes.

Perhaps not, but I'm not sure how useful those columns would be to a
monitoring system either.. I'd rather keep it simple.

Thanks!

Stephen