View Issue Details

IDProjectCategoryView StatusLast Update
0004760CentOS-5cyrus-saslpublic2011-10-29 07:49
Status newResolutionopen 
Platformi386OSCentOSOS Version5.5
Product Version5.5 
Target VersionFixed in Version 
Summary0004760: saslauthd using pam does not log rhost (remote host) IP/hostname in /var/log/secure
DescriptionBy default, sendmail uses saslauthd for SMTP AUTH; saslauthd uses PAM for authentication. However, log entries do not contain the remote host IP/hostname or requested login, even though this capability is built into PAM and other daemons who use PAM (e.g. sshd, imapd, etc.) do properly record both the rhost and requested login.

For example, when saslauthd experiences an auth failure, it logs to /var/log/secure:
Mar 9 06:56:41 hostname saslauthd[25858]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=

When sshd logs a similar failure, it logs:
Mar 8 14:02:26 hostname sshd[29059]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= user=someuser

Note that sshd's log entry includes both the remote host (rhost) and the requested login (user); saslauthd does not include either one (the requested login is neither in "logname" nor "ruser").

As such, saslauthd's PAM log entries are of very limited utility, and are useless for brute force detection utilities (e.g. BFD or fail2ban).
Steps To ReproduceFail an SMTP AUTH check and view the corresponding entry in /var/log/secure. Compare with a failed ssh login.
Additional InformationThe underlying problem is that in saslauthd/auth_pam.c, the auth_pam() function does not include an argument for the remote host, nor a means of determining it within the code. The requested login name _is_ passed but is not recorded in the log. Thus, saslauthd throws away the remote host information before even checking PAM, and also fails to set the appropriate PAM property to record the requested login name.

It should be quite possible to modify auth_pam to determine the remote host (using sasl_getprop, perhaps) and then to set the appropriate PAM parameters (via pam_set_item, perhaps). See last year's discussion on the Cyrus SASL mailing list:

A patch to do this in a _very_ old version of Cyrus SASL is available (, from when this code used to be in lib/checkpw.c... I am not entirely sure if this patch can be forward-ported to the v2.x (with the code now in saslauthd/auth_pam.c), but hopefully it can be.

I don't believe there is upstream intent to implement this, so it would be great if it could be implemented as a CentOS-specific patch, or if CentOS devs could provide impetus to upstream devs to implement this.
TagsNo tags attached.




2011-03-10 00:24

reporter   ~0012503

Additionally, the code should also be patched to pass the requested login (variable "login" within auth_pam()) to the _correct_ field of the pam data variable, so that it will be properly converted by pam_strerror() and thus properly logged, as well.


2011-03-10 11:47

reporter   ~0012505

Opened upstream (RHEL):


2011-10-29 07:49

reporter   ~0013665

A patch for v2.1.23, which also applies cleanly to v2.1.22, has been posted at CyrusSASL's bugzilla:

Would it be possible to backport the 2.1.23 patch to the Cyrus SASL v2.1.22 that is distributed with CentOS? There is no motion on this at RHEL but I consider this to be a security hole, because without this patch, saslauthd is not properly logging failures (i.e. hack attempts). It would be great if CentOS could backport this patch into the sasl v2.1.22 package for CentOS 5.x (and 6.x).

Issue History

Date Modified Username Field Change
2011-03-10 00:22 cepheid New Issue
2011-03-10 00:24 cepheid Note Added: 0012503
2011-03-10 11:47 cepheid Note Added: 0012505
2011-10-29 07:49 cepheid Note Added: 0013665