Since most of the hosts in CS are multi-user, such as machines in the ANN 104 lab, it is necessary to implement password/account controls to reduce the number of security vulnerabilities involving CS users having the same password at other sites that are not under our direct control; i.e., a user's account at Timbuktu gets his/her password compromised which happens to be the same password in use at Caltech, the Caltech user's account becomes vulnerable. Restricting access to a particular machine in CS will not effectively mitigate the risk since all CS machines share a unified account base (one password works for most if not all the machines within our scope). Hence, there is a clear requirement to have account/password controls to mitigate the risk of vulnerability.

Password/Account Policy

In CS, due to the number of new accounts every year (in the hundreds) it became necessary to form an enforceable policy regarding disposition of passwords and accounts. The policy currently being enforced is:

• passwords have a maximum lifespan of 180 days
• passwords have a minimum lifespan of 7 days
• accounts will automatically expire after 4 years
• users will be warned about expiration within a reasonable time before expiration
• users will be granted a short grace period after expiration
• upon expiration users are required to either
  • prove they are the legitimate owner of the account and prove their account is required for their work, or
  • have an instructor/faculty-level sponsor who will vouch for their identity and need for an account

Proof constitutes a picture ID, normally a Caltech ID in which the Caltech ID number is recorded into the CS user's LDAP entry for future reference, and the user claiming which course/research group they are associated with.

Password Controls

Shadow

CS has implemented shadow functionality in its LDAP implementation. Historically, shadow accounts were created for file-based /etc/passwd entries to protect the visibility of encrypted passwords and to enforce password policies such as expirations and strengths of authentication keys. Since LDAP is still a relatively new auth method in the scope of UNIX, password controls for LDAP-based accounts have only just been possible within the last few years. With shadow functionality, administrators are able to atomically control password age, which gives an administrator ability to "lock" a specific user account or enforce a global password change throughout the entire user base. (for more info, see 'man shadow' on any shadow-aware host.) With LDAP, there needs to be an LDAP shadow schema loaded into the LDAP server and the authentication/authorization system of the host needs to be LDAP-shadow aware, to perform the appropriate checks regarding password age controls. A typical /etc/nsswitch.conf file, for instance, already contains an entry for "shadow", but for LDAP it appears as:

shadow:         files ldap

Also, the authentication method in use that is LDAP-aware needs to also be shadow-aware. For instance, in CS, PAM (Pluggable Authentication Modules) is used and configured as follows. PAM modules are "stackable" and generally all reference one specific module, named "system-auth" on RedHat-based Linux and "common-"auth,account,password,session on SuSe-based Linux, and is configured as:

common-auth

auth     sufficient      pam_unix2.so    debug
auth     required        pam_ldap.so     use_first_pass

common-account

account  requisite       pam_unix2.so    debug
account  sufficient      pam_localuser.so
account  required        pam_ldap.so     user_first_pass

common-password

password requisite       pam_cracklib.so
password required        pam_unix2.so    use_authtok nullok debug
password required        pam_ldap.so     try_first_pass use_authtok

common-session

session  required        pam_limits.so
session  required        pam_unix2.so    debug
session  optional        pam_ldap.so
session  optional        pam_umask.so
session  optional        pam_env.so

The LDAP shadow-password specific configuration occurs on the "password" lines above. These are the lines of the configuration that are consulted when a user authenticates and/or changes the password for the account. The pam_unix2 portion keeps open the possibility that users local to the system (not in LDAP) may still login while enforcing the password policy. The pam_ldap portion defers the password policy to whatever pam_unix uses, which automatically will use "shadow" as a policy.

On the LDAP server, the schema constitutes:

objectclass ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY
    DESC 'Additional attributes for shadow passwords'
    MUST uid
    MAY ( userPassword $ shadowLastChange $ shadowMin $
          shadowMax $ shadowWarning $ shadowInactive $
          shadowExpire $ shadowFlag $ description ) )
attributetype ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.6 NAME 'shadowMin'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.7 NAME 'shadowMax'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag'
    EQUALITY integerMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

Hence, a shadow-enabled LDAP entry might appear as:

dn: uid=notyou,ou=People,ou=CS,o=Caltech,c=US
uid: notyou
cn: Not You
givenName: Not
sn: You
mail: notyou@cs.caltech.edu
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
uidNumber: 8316
gidNumber: 20003
homeDirectory: /home/notyou
gecos: Not You,,,
loginShell: /bin/zsh
shadowMin: 7
shadowMax: 180
shadowWarning: 10
shadowInactive: 7
shadowExpire: 15159
shadowLastChange: 13657

The above shadow- values, except for "shadowExpire", are fairly self-explanatory and are all calculated from shadowLastChange, which is the number of days since Jan 1, 1970. shadowExpire is the date, expressed in the number of days since Jan 1, 1970, in which the account (not password) will expire. Upon account expiration, the password need not be valid and will require administrative action to re-enable the account.

Host Access

Non-administrative user accounts are denied interactive/shell login access to the infrastructure. This is accomplished via PAM controls implemented on infrastructure nodes via access.conf. The authoritative PAM module, /etc/pam.d/common-auth, is retrofitted with:

account     required      pam_access.so

as part of the file. This PAM module consults /etc/security/access.conf, which contains either specific users allowed to gain access to the host while all others will be denied:

-:ALL EXCEPT leblancd psc sysadmin root:ALL

Root Login

The 'root' user exists on each node in the cluster, but in two general classes: workstations and servers. Root Login Policy conforms to these classes and is enforced by the following description. Workstations

Root login on workstations is only allowed at the local console (via password) and permitted via remote SSH only by SSH key. Root's public SSH key is distributed via central configuration management, but root's private SSH key does not exist anywhere accessible by users. The SSH private key for 'root' exists ONLY on removable media, such as a USB keychain, and is passphrase-protected. This restricts remote login as root to CS workstations for all users, except users in personal possession of the root SSH private key on removable USB storage media, and dramatically reduces the possibility of a root SSH key compromise. Additionally, if the USB storage device is lost or stolen, the passphrase associated with the SSH key will limit its use if someone obtains it. Servers/Infrastructure

Since it is sometimes administratively inhibiting to deny remote root login for an infrastructure node (for example remotely administering an LDAP server), the password for the 'root' account is different from the local 'root' password on a workstation. This policy mitigates the security risk that an attacker cannot simply gain root-level login access by compromising a workstation.

sudo

Policy

We do not recommend the use of sudo to non-staff/non-sysadmin users as there usually is a better way to solve issues than allowing root-level access, allowing users to solve their own problems, which in turn leads to non-uniformity and entropy in the systems we maintain.

-- DavidLeBlanc - 2019-10-17