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

Jeroen T. Vermeulen wrote:
> 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.
>
>
>
>   

Quite apart from security concerns, I find this design awkward. If we 
have a fallback mechanism, shouldn't it be available for all auth 
methods (except, as Tom rightly points out, for reject)? ISTM that the 
fallback behaviour of a rule should be specified separately from the 
auth method.

cheers

andrew