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

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.

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

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
solutionwould   be to reverse lookup the connection IP and check that hostname   against the host names in pg_hba.conf.
Wecould 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/>.

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.comPostgreSQL 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.comPostgreSQL 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] 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/

-- 
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?

On Mon, Jun 16, 2008 at 11:47:21AM +0200, Peter Eisentraut wrote:

> 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.

The obvious case for it (which is why I'm not arguing against using it
as such) is network renumbering.  If you renumber a network, right now
you have to update these files.  Today this isn't a big deal, but as
IPv4 addresses get scarcer and IPv6 addresses come online, this is
going to become a problem people have more often.  In large
deployments with a lot of postmasters and many people's hands
involved, one fewer change to manage would be a boon.  

Moreover, in managed networks, you don't always control when your IPs
will change or how.  Doing this by hostname could have advantages for
reliability, at the possible cost of startup performance.  One reason
to use DNS names rather than static /etc/host entries or IP
addresses is this resilience in the face of a changing network
infrastructure.  
> 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?

Well, there's one fewer thing that can be subverted.  But
authenticating from a host address is pretty weak authentication.  I'd
think the Morris worm teaches us that.  

Without DNSSEC, subverting the DNS is very close to trivial.  But, in
the presence of competent DNSSEC deployment, subverting the DNS
becomes just shy of impossible, so this might become a strategy
approximately as strong as authentication by host address.  You're
still trusting a connection on the basis of who it claims to be and
where it's coming from; that's hardly strong authentication.  I agree
with Andrew Dunstan that for any real world wide-scale uses, you want
to use some sort of strong authentication.

A

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

* Andrew Sullivan (ajs@commandprompt.com) wrote:
> On Mon, Jun 16, 2008 at 11:47:21AM +0200, Peter Eisentraut wrote:
> > 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.

There's an important use case that you've not listed- differentiating
authentication types by hosts.  For example, I have some systems which
are inside of my Kerberos realm and you should be using kerberos/gssapi
to auth to the databases from there, but I don't control everything and
so have to make exceptions for systems which need to connect but can't
use Kerberos for one reason or another.  The same also ends up being
true of applications (most notably Java-based ones, though that should
get better with GSSAPI support getting into JDBC and my moving to 8.3)
where users can't auth with kerberos/gssapi.  That tends to be most
easily managed on a per-host basis as well.

Additionally, we have systems with sensetive data on them where we like
to layer the security, and one of those is to say "users with admin
rights can connect from these hosts, while other users can only connect
from their systems".  All of these systems are behind NAT'ing devices or
are using RFC 1918 addressing as an isolated network so it's not clear
to me that using host names will help me in the IPv4 world.  We're
working with IPv6 though and are bringing up services on it and I expect
we will have to go through a renumbering before we run anything
production on IPv6, so being able to use host names at that point would
be nice.  Not as the only authentication mechanism, but as an additional
layer that an intruder would have to deal with.  We have DNSSEC running
also, and IPSEC, which lends security to the DNS service such that
forging DNS would be at least non-trivial.

All that said, we could drive it off some config option, I suppose.  I'm
not sure if that will satisfy those concerned about depending on
anything DNS, but it would limit the performance conerns, I'd think.
Thanks,
    Stephen

Thanks for all yours suggestions, use cases and opinion about this
thread, I saw that there are more things to consider than I was
thinking and this make me consider that it is a hard work to do for
now.

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

On Wednesday 25 June 2008 17:52, Dickson S. Guedes wrote:
> Thanks for all yours suggestions, use cases and opinion about this
> thread, I saw that there are more things to consider than I was
> thinking and this make me consider that it is a hard work to do for
> now.

Huh?  You should get started on it ... it will just take longer than you 
thought.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

On Thu, Jun 26, 2008 at 6:04 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On Wednesday 25 June 2008 17:52, Dickson S. Guedes wrote:
>> Thanks for all yours suggestions, use cases and opinion about this
>> thread, I saw that there are more things to consider than I was
>> thinking and this make me consider that it is a hard work to do for
>> now.
>
> Huh?  You should get started on it ... it will just take longer than you
> thought.

Hi Josh,

Yes it will take longer, in realy now I'm studyng how other softwares
(like SSH, Apache ...) do that to plan a way to implement it in the
backend, less impactant as possible. I'll send to list the
implementation plan for suggestions.

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