pgwire/hba: host name support for server.host_based_authentication.configuration

[mattcrdb]

CockroachDB's current HBA implementation only supports numeric CIDR specs for the client host filter column, or the all keyword.

PostgreSQL supports also hostnames, as well as the keywords samehost and samenet.

This issue is to also support hostnames in CockroachDB. Support for samehost and samenet can be considered in the PR to address this issue, but is not required.

The PostgreSQL algorithm is a bit expensive, in order to remain secure:

If a host name is specified (anything that is not an IP address range or a special key word is treated as a host name), that name is compared with the result of a reverse name resolution of the client's IP address (e.g., reverse DNS lookup, if DNS is used). Host name comparisons are case insensitive. If there is a match, then a forward name resolution (e.g., forward DNS lookup) is performed on the host name to check whether any of the addresses it resolves to are equal to the client's IP address. If both directions match, then the entry is considered to match. (The host name that is used in pg_hba.conf should be the one that address-to-name resolution of the client's IP address returns, otherwise the line won't be matched. Some host name databases allow associating an IP address with multiple host names, but the operating system will only return one host name when asked to resolve an IP address.)

A host name specification that starts with a dot (.) matches a suffix of the actual host name. So .example.com would match foo.example.com (but not just example.com).

When host names are specified in pg_hba.conf, you should make sure that name resolution is reasonably fast. It can be of advantage to set up a local name resolution cache such as nscd. Also, you may wish to enable the configuration parameter log_hostname to see the client's host name instead of the IP address in the log.

cc @aaron-crl

Jira issue: CRDB-5112

[knz]

Thanks Matt for filing this. @aaron-crl I have pasted the pg algorithm in the issue desc at top, can you check that their security claim about the double DNS lookup is sound?

[aaron-crl]

Just to understand context: Is this (1) something we want to do because pg does it already and we want to implement it as best we can, or do we want to (2) consider the wisdom of implementing this feature altogether?

To your direct question @knz : DNS isn't a terrible secure protocol (in spite of it's ubiquity). I don't feel that relying on reverse-forward DNS in this way is a good security feature as there are very practical (though constrained) attacks against this approach. If we follow the pg pattern we will be susceptible to those too.

[knz]

DNS isn't a terrible secure protocol (in spite of it's ubiquity). I don't feel that relying on reverse-forward DNS in this way is a good security feature as there are very practical (though constrained) attacks against this approach. If we follow the pg pattern we will be susceptible to those too.

That's what I was fearing, thanks for confirming. We'll need to brainstorm the user stories that name-based filtering is enabling, and find replacements for those.

[github-actions[bot]]

We have marked this issue as stale because it has been inactive for 18 months. If this issue is still relevant, removing the stale label or adding a comment will keep it active. Otherwise, we'll close it in 10 days to keep the issue queue tidy. Thank you for your contribution to CockroachDB!