Re: Information of pg_stat_ssl visible to all users

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Information of pg_stat_ssl visible to all users
Date: 2015-07-07 18:48:30
Message-ID: 559C1EFE.5050500@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/07/2015 11:29 AM, Stephen Frost wrote:
> * 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.

So what about making just pid, ssl and compression available? That's
mostly what anyone would want to monitor, except for periodic security
audits. Audits could be done by superuser, no problem.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-07-07 19:21:50 Re: Missing latex-longtable value
Previous Message Stephen Frost 2015-07-07 18:29:49 Re: Information of pg_stat_ssl visible to all users