Computers in public labs, such as the Student Technology Centers maintained by UITS, allow just about any university-affiliated person to walk up and log in. Maintainers of these computers might use the Directory Access utility to make authentication work against LDAP or Active Directory. This brief article covers a dangerous side-effect that could arise from this approach to centralized authentication.
Mac OS X, as of version 10.2, uses a modular authentication architecture called PAM. Simply put, PAM lets small software modules handle each available type of authentication, authorization, password changing, and account management. Applications, instead of implementing these facilities on their own, can hand off control to PAM modules as configured by the system administrator.
For example, if you want to perform LDAP authentication using PAM, you'd need the pam_ldap module. This module knows everything there is to know about LDAP authentication so applications don't have to. When application developers make their code PAM-aware, it suddenly supports all the authentication mechanisms (LDAP, Kerberos, Oracle, NetInfo, /etc/passwd, etc.) for which PAM modules exist. Mac OS X comes with a PAM module called pam_securityserver, which authenticates against whatever service is configured in Directory Access.
The SSH service (sshd) on Mac OS X is PAM-aware. It knows what PAM modules to use by looking in /etc/pam.d/sshd:
# login: auth account password session auth required pam_nologin.so auth sufficient pam_securityserver.so auth sufficient pam_unix.so auth required pam_deny.so account required pam_permit.so password required pam_deny.so session required pam_permit.so
Let's focus on the authentication modules only (those lines that begin with auth). PAM will try each of these modules in order. Where it stops depends on the word in the second column (here, required or sufficient) and whether the module succeeds or fails. pam_nologin is very simple; it always succeeds unless /etc/nologin exists (useful for keeping people out during system maintenance). Next is pam_securityserver; only if it fails do we proceed to pam_unix, which uses conventional Mac OS X authentication methods.
So by default, sshd allows access based on successful authentication using the Directory Access configuration. If Directory Access is configured to authenticate against Active Directory, for example, any user with a valid Active Directory account could then SSH into the computer -- probably not what we want in a public lab! Sure, you may want remote administrative access to lab computers using SSH. But you probably only want one user at a time to be logged in and only from the console. To close this potential back door, comment out the pam_securityserver line:
# auth sufficient pam_securityserver.so
System administrators will still have SSH access to their local accounts thanks to the pam_unix line, but other users will be denied SSH access.