Abstract
From the ARC materials:
This project is related to the [[SPARKS>>Project sparks.WebHome]] project, falls under the SPARKS
umbrella case to be presented at PSARC on 04/19/2006, and has a soft
defpendency on SPARKS.
Some directories require that lookups be "self-credentialled,"
meaning that clients use user credentials, as opposed to host or
"proxy" credentials.
The Solaris login process, however, works in such a way that
directory lookups must be performed prior to the point at which user
network authentication credentials are available. A chicken and egg
problem ensues.
Further, network authentication (single sign-on) is not well
integrated with PAM, which is related to the chicken-egg problem in
that delegated credentials and/or authorization-data could be used in
certain contexts in addressing the chicken-egg problem, but not
easily without a closer tie between PAM and network authentication.
This project revamps the Solaris login process to allow for
directories that require self-credentialled lookups for information
needed during the Solaris login process and to better integrate
network authentication with PAM.
We borrow from JAAS the notion of a "Subject" object that represents
information about users needed during the login process, and we tie
this notion to PAM, allowing PAM modules to provide subject
information, which in turn breaks the chicken-egg problem by
eschewing name service lookups in PAM applications. Additionally we
move certain tasks from GSS-API applications to PAM, such as
authorization of remote principals to Unix user accounts and handling
of credential delegation.
These changes will also enable us to better cope with future Solaris
process credentials extensions and with infrastructures and
authentication mechanisms that deliver user process credential
information through network authentication.
Summary
Reno extends PAM as follows:
Adds a //*PAM~_USER~_TYPE** item to identify the type of user account named by PAM~_USER. Solaris PAM modules will, of course, only support "Unix" user accounts.
Adds a //*PAM~_USER~_INFO** item by which PAM applications can pass a **userinfo~_t** object to PAM modules, which can then fill in information about the PAM~_USER that is relevant to the login process (see below).
- Related to this, there is a new API, the User Info API. A User Info object is a template that represents everything about an authenticated user that must be known at logon-time, such as:
- UID
- Primary GID
- Supplementary GIDs
- Home directory
- Shell
- Default and limit privilege sets
- Project
- User account type (i.e., user vs. role)
as well as how to apply such templates to processes.
Adds new items, //*PAM~_GSS~_MECH**, **PAM~_GSS~_NAME** and **PAM~_GSS~_CRED** by which PAM applications can communicate to PAM modules informations about client principals authenticated with the GSS-API by passing gss~_OID, gss~_name~_t and gss~_cred~_id~_t objects, respectively.
PAM modules and applications will be modified accordingly.
Among other interesting changes: sshd(1M), in.telnetd(1M), and friends will no longer be responsible for handling authorization of client principals to Unix accounts, nor for handling of delegated credentials. Additionally, pam_ldap(5) and pam_krb5(5) will, when self-credentialled LDAP is configured, perform self-credentialled lookups in the directory and fill in applications' userinfo~_t objects.
Backwards compatibility is addressed as follows:
- Existing module behave as usual when PAM~_USER~_INFO is not set;
- Modules will have a nouserinfo argument to disable new behaviour even when PAM~_USER~_INFO is not set;
- Applications will fallback on using name services to discover users' UIDs, GIDs, etc.. when PAM modules fail to fill in the applications' userinfo~_t object.
Per-User PAM Configuration
A project related to Reno, PSARC 2005/275, extends the PAM framework by adding a new PAM function, **pam~_eval(3PAM)**, that loads the PAM configuration in a file named by its argument, and evaluates the current service module for the current PAM service, returning the result to the caller. This function is intended to be called by PAM modules, specifically a new Solaris PAM module: **pam_user~_policy(5)**, which determines a configuration file to evaluate by first looking for the PAM_USER's **pam~_policy** user_attr(5) key, falling back on the **pam~_policy** of the first RBAC profile granted in policy.conf(5) that has such a key.
Reno depends on this functionality.
Documents
A slightly updated version of the brief in the ARC commitment materials directory. (Some of the man page links therein are broken; they will be fixed shortly.)
For now here are the man pages for the User Info API: