TODO Item: Allow pg_hba.conf to specify host names along with IP addresses

Dickson S. Guedes wrote:

Hi all,

There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.

I'd like to work on this feature, if nobody is working too and no
objection exists.

Please do --- I know of no one working on that.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Jun 12, 2008, at 12:25 PM, Bruce Momjian wrote:

Dickson S. Guedes wrote:

Hi all,

There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.

I'd like to work on this feature, if nobody is working too and no
objection exists.

Please do --- I know of no one working on that.

Oooh please do!

Bruce Momjian wrote:

Dickson S. Guedes wrote:

Hi all,

There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.

I'd like to work on this feature, if nobody is working too and no
objection exists.

Please do --- I know of no one working on that.

The reason it wasn't done years ago was that there was disagreement on
the way it should work. And the TODO actually lists several alternatives:

Host name lookup could occur when the postmaster reads the
pg_hba.conf file, or when the backend starts. Another solution would
be to reverse lookup the connection IP and check that hostname
against the host names in pg_hba.conf. We could also then check that
the host name maps to the IP address.

So before you start actually working on it, let's see if we have a
better level of agreement on what it should do. Personally, I favor
hostname lookup on backend start but none of the others.

cheers

andrew

On Fri, Jun 13, 2008 at 12:47:22PM -0400, Andrew Dunstan wrote:

The reason it wasn't done years ago was that there was disagreement on the
way it should work. And the TODO actually lists several alternatives:

Host name lookup could occur when the postmaster reads the
pg_hba.conf file, or when the backend starts. Another solution would

It needs to happen at authentication time. I'm not sure whether
"reads the pg_hba.conf" or "backend starts" is the right way to say
that, but it must happen only when you're actually authenticating the
host entry.

This is because DNS RRs have a TTL on them, so looking up the host at
any moment other than when you're actually doing the authentication is
prone to error.

be to reverse lookup the connection IP and check that hostname
against the host names in pg_hba.conf. We could also then check that
the host name maps to the IP address.

There is, curiously, an existing Internet Draft currently in WGLC at
the dnsop working group at the IETF that warns explicitly against
using hostname forward and reverse matching checks as a security
mechanism, without having other options. So if the mechanism is going
to force matching forward and reverse data, then I urge whoever
implements this to make it possible to turn that matching check off,
because it won't work reliably. The draft is available from
<http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/&gt;.

By the way, in the context of DNSSEC, a matching check might not add
anything, but a check for existing signed reverse data may. That is,
if you have authenticated forward zone data and you have authenticated
reverse zone data, you can be confident that you have the right
hostname even if the forward and reverse hostnames don't match.

A
--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

Andrew Dunstan <andrew@dunslane.net> writes:

The reason it wasn't done years ago was that there was disagreement on
the way it should work. And the TODO actually lists several alternatives:

IIRC, the major reason there was disagreement was the prospect of
unacceptable performance from any of the easy or obvious
implementations. As Andrew S notes, you can't just do the lookups
once at postmaster start; but resolving a pile of hostnames during
each connection is pretty unpleasant, especially if the DNS server
isn't local. (And then there are the effective-DOS implications if
the DNS server is down altogether.)

The attraction of the reverse-lookup approach is that you do only
one lookup, on the actual connection IP, rather than having to
resolve every hostname in the file to see if it matches. However
that way had disadvantages of its own, which I don't recall at the
moment. I think at least some of the issues had to do with security,
ie how much can you trust an answer from a remote DNS server.

Check the archives before you start implementing ...

regards, tom lane

On Fri, 2008-06-13 at 13:26 -0400, Andrew Sullivan wrote:

On Fri, Jun 13, 2008 at 12:47:22PM -0400, Andrew Dunstan wrote:

The reason it wasn't done years ago was that there was disagreement on the
way it should work. And the TODO actually lists several alternatives:

Host name lookup could occur when the postmaster reads the
pg_hba.conf file, or when the backend starts. Another solution would

It needs to happen at authentication time. I'm not sure whether
"reads the pg_hba.conf" or "backend starts" is the right way to say
that, but it must happen only when you're actually authenticating the
host entry.

The best of both ideas would be to have an option inside pg_hab.conf to
indicate when lookup occurs. Some parts of a network are static, others
are not, so a global option would not be useful.

The default should be at authentication time as Andrew Sullivan
suggests, so that correctness is the default. If the user knows a
portion of their network is static, then the lookups can be done ahead
of connection time to reduce connection latency, as Andrew Dunstan
suggests.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

On Fri, Jun 13, 2008 at 4:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

The reason it wasn't done years ago was that there was disagreement on
the way it should work. And the TODO actually lists several alternatives:

IIRC, the major reason there was disagreement was the prospect of
unacceptable performance from any of the easy or obvious
implementations. As Andrew S notes, you can't just do the lookups
once at postmaster start; but resolving a pile of hostnames during
each connection is pretty unpleasant, especially if the DNS server
isn't local. (And then there are the effective-DOS implications if
the DNS server is down altogether.)

Yes, if DNS server is down during a init connection, or server
startup, we can have problems.

The attraction of the reverse-lookup approach is that you do only
one lookup, on the actual connection IP, rather than having to
resolve every hostname in the file to see if it matches.

SSH uses an approach like that.

However that way had disadvantages of its own, which I don't recall at the
moment. I think at least some of the issues had to do with security,
ie how much can you trust an answer from a remote DNS server.
Check the archives before you start implementing ...

I'm seeing alternatives and studing the code and the email replies,
but not start coding yet.

Thanks Tom.

--
[]s
Dickson S. Guedes
-------------------------------------
Projeto Colmeia - Curitiba - PR
(41) 3254-7130 ramal: 27
http://makeall.wordpress.com/
http://pgcon.postgresql.org.br/
http://planeta.postgresql.org.br/

Andrew Sullivan wrote:

This is because DNS RRs have a TTL on them, so looking up the host at
any moment other than when you're actually doing the authentication is
prone to error.

Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. At the time of actually checking you need only get
a new answer for those that expired.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:

Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. At the time of actually checking you need only get
a new answer for those that expired.

This is not behavior we'd want to put into the postmaster, though,
and it's hard to see how to manage it otherwise. (Well, maybe a new
postmaster child process just for this, but I find it hard to believe
the feature is worth that.)

regards, tom lane

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. At the time of actually checking you need only get
a new answer for those that expired.

This is not behavior we'd want to put into the postmaster, though,
and it's hard to see how to manage it otherwise. (Well, maybe a new
postmaster child process just for this, but I find it hard to believe
the feature is worth that.)

Indeed.

The only circumstance in which this feature should be used is probably
where you have control over the zones involved. For remote connections
I'd far rather have an open address specification and require SSL with
client side certs.

The potential for self-inflicted pain from this feature does worry me a bit.

cheers

andrew

On Fri, Jun 13, 2008 at 08:51:19PM +0100, Simon Riggs wrote:

The best of both ideas would be to have an option inside pg_hab.conf to
indicate when lookup occurs. Some parts of a network are static, others
are not, so a global option would not be useful.

We would point and laugh at people who thought that something was
"static" inside PostgreSQL, and depended on that for something
critical without some pretty heavy-duty locks. Are we really
proposing to offer an authentication mechanism that depends on
something as flimsy as hostname lookups in the DNS, and then not
insist that the bare minimum of integrity check ("I checked this DNS
lookup at connection time") is the rule?

DNS is a distributed database. Surely the least we can demand is that
the lookup happen when the naive think it will (i.e., at the time the
connection from that hostname happens).

If the user knows a portion of their network is static,

If there were the slightest evidence that users historically believed
in such "knowledge" correctly, then I might have some sympathy for
this. The fact is that DNS (at least without DNSSEC) is one of the
areas in which sysadmins have the worst record of trust to this day.
I think we'd be fools to encourage such trust. If you don't look up
at _least_ at connection time, this feature should be rejected on the
grounds that it opens a new authentication hole a mile wide.

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

On Fri, 13 Jun 2008 16:14:13 -0400 Alvaro Herrera wrote:

Andrew Sullivan wrote:

This is because DNS RRs have a TTL on them, so looking up the host at
any moment other than when you're actually doing the authentication is
prone to error.

Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. At the time of actually checking you need only get
a new answer for those that expired.

That's too much overhead in the postmaster.
A better way would be some documentation how one can improve the DNS
performance, like using an external DNS cache ect.

I would also like to see a note that the DNS lookup could seriously
slow down the authentication process.

Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

Alvaro Herrera wrote:

Perhaps the solution to this problem is to do the lookups and store the
TTL of each answer. �At the time of actually checking you need only get
a new answer for those that expired.

Isn't that what a local DNS caching-only server would accomplish?

Dickson S. Guedes wrote:

SSH uses an approach like that.

It would probably be a good idea to check how other programs deal with
hostname lookups during authentication. Programs like SSH, Apache, and Squid
come to mind.

On Fri, 2008-06-13 at 22:38 -0400, Andrew Sullivan wrote:

If you don't look up
at _least_ at connection time, this feature should be rejected on the
grounds that it opens a new authentication hole a mile wide.

That seems conclusive to me.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

On Sun, Jun 15, 2008 at 11:53:57PM +0200, Peter Eisentraut wrote:

Isn't that what a local DNS caching-only server would accomplish?

Only if you looked up the DNS name at auth time :)

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

On Sun, Jun 15, 2008 at 11:56:35PM +0200, Peter Eisentraut wrote:

It would probably be a good idea to check how other programs deal with
hostname lookups during authentication. Programs like SSH, Apache, and Squid
come to mind.

There is actually a great deal of controversy about most of this
hostname-based authentication, particularly in the absence of DNSSEC.
If anyone implementing this is interested in the controversy, I have a
huge mail archive of it (because I'm the current editor of the IETF
working group document on this, and therefore have received much hate
mail on the topic). I think it's all summarised in the draft[1]http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/ I
mentioned upthread. Since that's possibly about to go to IETF last
call, it'd be a good time for someone planning to implement something
to look at that document, and report on whether it provides any useful
guidance at all. I'd be keenly interested in hearing the verdict.

A

[1]: http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/
http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

Am Montag, 16. Juni 2008 schrieb Andrew Sullivan:

Since that's possibly about to go to IETF last
call, it'd be a good time for someone planning to implement something
to look at that document, and report on whether it provides any useful
guidance at all. �I'd be keenly interested in hearing the verdict.

Well, this mainly says that a system that relies on DNS and reverse DNS should
not be the default and only security mechanism. I think we can work with
that. I'm not sure this actually tells us anything new, but at least it's
written down in one place now.

Am Donnerstag, 12. Juni 2008 schrieb Dickson S. Guedes:

There is a TODO Item to allow pg_hba.conf to specify host names along
with IP addresses.

I'm a bit curious how useful in practice this would actually be. Obviously,
you want to use host names to simplify the management of hosts, currently
being done with IP addresses. But how widely useful is it really to
authenticate a bunch of hosts in different ways? I'd say the standard case
is localhost vs everything else. Or perhaps localhost vs LAN vs rest of the
Internet. In neither of these cases , using host names helps much.

We have people here concerned about security of DNS, rightly so. But what
about relying on IP addresses or, by extension, MAC addresses for security;
is that safe?

So what are the use cases for having more than about 4 or 5 lines in
pg_hba.conf, and how would the ability to use host names help there?