saslauthd SASL_IPREMOTEPORT -> PAM_RHOST

[Lorenzo M. Catucci]

On 05/22/2011 09:20 PM, Amir 'CG' Caspi wrote:
> Lorenzo,
>
> Also, does your patch pass the requested login name to saslauthd? I didn't
> see that it did. That would also be a great inclusion, so we could exclude
> dictionary attacks from potentially legitimate users. Certainly not as
> crucial as the remote IP, though.
>
> I've updated my RHEL bug to include a link to your patch - hopefully we can
> get it included upstream (especially if one of them applies cleanly to 2.1.22).
>
> Thanks!


Amir,
	I just checked the 2.1.23 patch applies with just some line shift
to 2.1.22. I have no handy way to test it and I have no experience with
SRMPs, specs and the like, since my systems are debian based. I'd be VERY 
grateful if you could try yourself to create a patched RPM for a test
system of yours!

As for the "pass the requested login name", saslauthd does know the login
name, as it must be passed to the auth handlers; if you set the syslog
level for the authpriv syslog destination to debug, you'll be able to see
lines like the following ones:

May 23 09:53:36 test saslauthd[28570]: pam_unix(svc:auth): check pass; user 
unknown
May 23 09:53:36 test saslauthd[28570]: pam_unix(svc:auth): authentication 
failure; logname= uid=0 euid=0 tty= ruser= rhost=127.0.0.1 **
May 23 09:53:38 test saslauthd[28570]: DEBUG: auth_pam: pam_authenticate 
failed: Authentication failure
May 23 09:53:38 test saslauthd[28570]: do_auth         : auth failure: 
[user=cg] [service=svc] [realm=] [remote=127.0.0.1;42002] [mech=pam] 
[reason=PAM auth error] **

Since that is the default configuration on my systems, I didn't get
the problematic * line, since all you need is shown in **.

I don't make any promise, but I'll try to understand this glitch.

Thank you very much, yours

	lorenzo