1. Background ------------- Customers have (ab)used the passwd compat functionality of nsswitch for years. It is typically used it to restrict which users can login to a given host, while still allowing the host to be part of the same name service domain as others. Often this is done on mail and home directory (NFS) servers that users aren't allowed to run interactive jobs on but their uid's need to be known for authentication and/or quotas etc. If you have complex netgroups and use them with passwd compat mode then there can be a noticeable and significant delay on every getpw*() call. This is due to the need to walk the netgroup to find the user, this is made worse because netgroups are not cached by nscd (but that is a story for another day). The source code for an example PAM module it is included in an InfoDoc on SunSolve and in the OpenSolaris security community.I know that it has been given to several customers. I occasionally get emails from people in SunService thanking me since it helped them close a customer call where there was complaint about the performance on netgroups and passwd compat. I've recently done some data mining on the pam.conf files that are held in the US customer explorer database and confirmed that my module or ones that sound very like it are being used by several customers. A similar module exists on most Linux distributions. 2. Proposal ----------- Introduce a new PAM module called pam_list.so. This module only implements pam_sm_acct_mgmt(3pam) and determines wither or not to return success or failure based on the value of PAM_USER/PAM_RHOST and its configuration. The configuration of the module is all done via arguments to the module specified in pam.conf. The reason for this rather than a single config file is to allow the module to be used differently depending on which service stack it is in (or even to be listed multiple times in the same stack with a different config). Either one of: allow= or deny= can be specified. If neither is specified then the module parses the local /etc/passwd file looking for +/- entries and uses those instead of a separate file. The contents of the file are a list of usernames and/or netgroups, where netgroups begin with the '@' symbol. If allow= is specified then a exact match of PAM_USER in the file will cause the module to return PAM_SUCCESS. If the user is not found then PAM_PERM_DENIED is returned. If deny= is specified then a exact match of PAM_USER in the file will cause the module to return PAM_PERM_DENIED and if the user is not found then PAM_SUCCESS is returned. Since there are several different methodologies used by our customers for building netgroups the module needs to be flexible to how the customer has configured the netgroup tuples. The following optional config options can change the behavior of how the innetgr() call is made: user - Just match the user. nouser - Don't match the user. host - Just match the host. nohost - Don't match the host. user_host_exact - User and host must match in the same netgroup. This allows the following different netgroup styles: bar (hosta, usera, -) bar (hosta, -, - ) bar (- , usera, - ) bar ( , usera, ) bar (hosta, , ) it also allows control over the users location if need be. rhost in the above is the contents of PAM_RHOST if it is set. If PAM_RHOST is not set then we use the hostname of the local machine as rhost if host checking is turned on. The module will not be configured for any service by default, nor would it be in the pam.conf commented out for any service, as such there are no updates to the i.pamconf class action script included in this project. This is deliberately a file on the local host rather than something held in LDAP against the user or host. There are other means for restricting authentication when pam_ldap is used, these based on the capabilities of the LDAP server and are sometimes specific to a given LDAP server. There is also purposely no admin command, the customers requesting this functionality want a raw file as that is what they already use on Linux or on Solaris with the existing open source module. 3. allow/deny file format ------------------------- The comment char for this file is '#'. Comments are only complete lines, in-line comments are not supported. Each line in the file is either a username or a netgroup. Netgroups begin with the '@' char otherwise it is assumed to be a username. 4. Examples ----------- 4.1 Only non role admin users can login to local devices login account requisite pam_roles.so.1 login account requisite pam_list.so.1 allow=/etc/local/admins login account required pam_unix_account.so.1 4.2 Admin uses don't need to do Kerberos when using ktelnet and remote is a a trusted host, other users do. ktelnet account requisite pam_roles.so.1 ktelnet account sufficient pam_list.so.1 allow=/etc/thostad user_host_exact ktelnet account binding pam_krb5.so.1 ktelnet account required pam_unix_account.so.1 4.3 Ban a certain users from this host regardless of where they come from and how they got here. other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_list.so.1 deny=/etc/banned-users nohost 5. Interface/Release Taxonomy ----------------------------- Exported Interfaces +-----------------------------------------------------------------+ | /usr/lib/security/$ISA/pam_list.so.1 | | | functionality & arguments | Commited | +---------------------------------------------+-------------------+ | allow/deny file format | Commited | +---------------------------------------------+-------------------+ Release binding is micro/patch. 6. Supporting Materials ----------------------- materials/pam_list.5 4294674 Restrict logins using netgroups without using passwd_compat mode in NSS