Re: RFC: Non-user-resettable SET SESSION AUTHORISATION

On Sat, May 23, 2015 at 8:14 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote:
>> On Tue, May 19, 2015 at 3:00 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> > As long as the cookie is randomly generated for each use, then I don't see a
>> > practical problem with that approach.
>>
>> If the client sets the cookie via an SQL command, that command would
>> be written to the log, and displayed in pg_stat_activity. A malicious
>> user might be able to get it from one of those places.
>>
>> A malicious user might also be able to just guess it. I don't really
>> want to create a situation where any weakess in pgpool's random number
>> generation becomes a privilege-escalation attack.
>>
>> A protocol extension avoids all of that trouble, and can be target for
>> 9.6 just like any other approach we might come up with. I actually
>> suspect the protocol extension will be FAR easier to fully secure, and
>> thus less work, not more.
>
> All true. Here's another idea. Have the pooler open one additional
> connection, for out-of-band signalling. Add a pair of functions:
>
> pg_userchange_grant(recipient_pid int, "user" oid)
> pg_userchange_accept(sender_pid int, "user" oid)
>
> To change the authenticated user of a pool connection, the pooler would call
> pg_userchange_grant in the signalling connection and pg_userchange_accept in
> the target connection. This requires no protocol change or confidential
> nonce. The inevitably-powerful signalling user is better insulated from other
> users, because the pool backends have no need to become that user at any
> point. Bugs in the pooler's protocol state machine are much less likely to
> enable privilege escalation. On the other hand, it can't be quite as fast as
> the other ideas on this thread.

I'm sure this could be made to work, but it would require complex
signalling in return for no obvious value. I don't see avoiding a
protocol extension as particularly beneficial. New protocol messages
that are sent by the server cause a hard compatibility break for
clients, but new protocol messages that are client-initiated and late
enough in the protocol flow that the client knows the server version
have no such problem.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company