Re: "Optional ident" authentication - Mailing list pgsql-hackers

On Sun, November 26, 2006 23:51, Tom Lane wrote:
>> Is there a reason other than existing code why HBA should not allow
>> "ident" to be combined with other authentication methods?
>
> How about that it's a bad idea?  A combo method seems ideally suited
> to security holes, in the form of letting through unintended logins.

Well, that's why I'm asking.  But I was hoping for something more concrete
than "it could possibly be misconfigured."  Especially when we still
generate default configs that say "trust" for all local logins!

The Debian package does come with a safer default config using "ident
sameuser."  For a packager-maintained setup like that, where you know
beforehand that both the backend and the system do PAM, it might make
sense to have that passwordless "ident sameuser" login on local
connections but use e.g. "pam login" for the rest--including cross-user
local logins.

As far as I can make out, the only way to make "optident" unsafe is to
have  a matching rule following that it either (1) is a "trust" rule or
(2) demands a plaintext password login on a non-local, unencrypted
connection (and actually gets used while someone is intercepting the
packets).  If you configure either of those, I'd say you're on thin ice
anyway.  It certainly goes right against the "increasingly strict,
decreasingly specific" guideline.


> ... and this particular approach would break more installations'
> security than I really want to think about.  It's not really a new ident
> method, it's a very fundamental change in the semantics of pg_hba.conf.

Sure.  But only when people use it, and then it can be used for good or
for evil like anything else.  A new authentication method that's not in
the default config doesn't affect anyone's installation all by itself.


> As an example of how much it would change things, the "reject" auth
> option would become a useless no-op.

How?  Why?  Naturally I tested it in combination with "reject" and it
still rejected just as it should: "optident X" plus "reject" matching the
same login add up to a regular "ident X."  Same for "optident X" when it's
not followed by another matching rule: if you're mapped you're in, if
you're not mapped you're out.  It just gives you the ability to follow up
with a fallback rule that actually authenticates.

The simplest way to keep optident secure is by pairing it with a second
rule that has the same fields to the left of the authentication method,
but gives a stricter authentication method.  Second-simplest way: don't
use plaintext passwords on unencrypted, non-local connections across
unsafe networks and don't do "trust" anywhere.  Third-simplest way: follow
the existing guideline of starting with specific, permissive rules and
working your way towards broad, strict rules.

If there are any problems with that, of course I'd like to hear about them.


Jeroen