On Mon, May 17, 2021 at 11:18 PM Chapman Flack <c...@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/
