Re: allow specifying direct role membership in pg_hba.conf

On Mon, May 17, 2021 at 11:18 PM Chapman Flack <chap@anastigmatix.net> wrote:
>
> On 05/17/21 16:35, Magnus Hagander wrote:
> > So you're saying that some entries int he parameter section would
> > depend on the db/user/ip combo and some would depend just on the ip?
>
> I don't *think* that's what I was saying. What I was thinking was this:
>
> The pg_hba.conf file is an ordered list of entries. Each entry can specify
> a (broad or narrow) set of IPs it applies to, a (broad or narrow) set of
> databases it applies to, and a (broad or narrow) set of users it applies to.
>
> Also, in this hypothetical, it can specify a min protocol version.
>
> Right now, we're doing something like this:
>
> 1. accept an incoming connection, learning the client IP
> 2. SSLRequest message leads to negotiating TLS
> 3. StartupMessage supplies the desired database and user name
> 4. pg_hba entries are consulted once and filtered down to the first one
> applicable to the client IP, database, and username (and SSLness)
> 5. that entry is used for authentication
>
>
> I suggested only:
>
> Insert step 1½, filter the pg_hba entries down to only those that could
> possibly accept a connection from this IP address. This is an improper
> subset of the whole list, and an improper superset of the singleton to be
> generated later in step 4.
>
> Step 2 still negotiates TLS, but can fail early if the protocol would
> be older than the oldest allowed in the pre-filtered list.

Nop, this is *exactly* what I'm referring to as being a bad idea.

Step 1 1/2 in this *ignores* the fact that you may have specified a
restriction on username and database name in pg_hba.conf, because it
hasn't seen them yet. Thus,  a parameter such as min_tls_version would
not respect the username/databasename field, whereas other parameters
would. That is a massive risk of misconfiguration.

I mean, if you have
hostssl somedatabase someuser 10.0.0.0/24 gss
hostssl somedatabase supseruser 10.0.0.0/24 gss tls_min_version=1.3

One would reasonably expect that "someuser" can connect with whatever
the default version i for tls_min_versino, whereas "superuser" would
require a minimum of 1.3. But that's *not* what would happen --
superuser would also be allowed to connect with a lower version if
that's allowed in the global set.


> Step 4 takes that pre-filtered list and completes the restriction down to
> first entry matching the IP, database, and username. This should be the
> same singleton it would generate now. But it can fail-fast if that entry
> would require a higher protocol version than what's been negotiated,
> before sending the corresponding authentication request message, so no
> authentication data will be exchanged over a less-secure channel than
> intended. However, the user, database name, and options in the Startup
> message might have been exposed over a lower TLS version than intended.
> Maybe that's not the end of the world?

That is exactly the problem. And while that may hold true of current
auth methods, it may not hold true of all. And it could still trigger
things like an ident callback if that is allowed etc.

So I stand by thinking this is the wrong place to solve the problem. I
agree it would be good to be able to do it, but I don't agree on
overloading it on pg_hba.conf, which is complicated enough already.
And for security config, simplicity is pretty much always better.

--
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/