PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ]

[Bart Blanquart]

On 02/04/09 21:08, Gary Winiger wrote:
 >> Timer is set for Friday 30th Jan 2009.  Release binding is patch but 
with no intention to backport to Solaris 10.
 >
 >     IMO, any backport would require integration with the S10 RBAC
 >     interfaces including SMC.  For this particular project, that
 >     looks to me like a testing effort.  But should it be more than
 >     testing, I'm reluctant to gage that Patch is without impact.
 >     I'd be happier with a Minor release binding.

Though we don't have the intention to backport to S10 there are business 
reasons that may make such a backport desirable, so I would like to 
retain patch binding.

I don't see any impact whasoever to SMC from this change: SMC already 
handles the nearly 130 authorizations, the 25+ rights profiles with 
authorizations, and the "Basic Solaris User" rights profile with about 
20 authorizations. Adding a couple authorizations or modifying a rights 
profile won't make a difference... which a quick test just now confirms.

 >> The solaris.login authorizations are checked for if the relevant
 >> pam_data items are present.
 >
 >     Nit these are PAM items, they are NOT PAM data viz.
 >     pam_set_item() vs pam_set_data()

Noted. The documentation will be updated to reflect this.

 >> +----------------------------+-----------------------------------+
 >> | Data item                  | Required authorization            |
 >> +----------------------------+-----------------------------------+
 >> | PAM_RHOST=<any value>      | solaris.login.remote              |
 >> +----------------------------+-----------------------------------+
 >> | PAM_TTY=/dev/console       | solaris.login.console             |
 >> +----------------------------+-----------------------------------+
 >> | PAM_TTY=<any other value>  | solaris.login.local               |
 >> +----------------------------+-----------------------------------+
 >
 >     What is the precedence when both PAM_RHOST and PAM_TTY are
 >     specified?

If PAM_RHOST is present its authorization will be checked for and the 
PAM_TTY authorization will not be checked. The documentation will be 
updated to reflect this.

 >> The solaris.login authorizations are granted to all accounts via
 >> "Basic Solaris User", so the behaviour of the system remains the same
 >> in default configurations.
 >
 >     Since we do not want customers modifying Sun delivered Rights
 >     Profiles, IMO it would be better to add a new Rights Profile
 >     and add that to PROFS_GRANTED, or to add solaris.login.* to
 >     AUTHS_GRANTED.
 >

Customers that want to deviate from the default profile can define their 
own "Site Solaris User" and assign that in PROFS_GRANTED. I don't see 
the value in adding another default profile as "Basic Solaris User" is 
just that.

 >> (While at this point there is nothing fundamentally different between
 >> a "rights profile" as assigned to users and a "policy profile" as
 >> specified as argument here they are conceptually different: the first
 >> assigns all rights and auths it contains, while the latter is used to
 >> check for any of the auths -- hence the difference in terminology.)
 >
 >     Has the project team checked with the RBAC project team
 >     (specifically Glenn Faden) about this difference?  Similarly
 >     has the project team checked about substitutable tokens (below)?
 >     Has the project team gotten the RBAC team's agreement?
 >     Has the project team checked with the Solaris Platform Security
 >     team (specifically Craig Payne) on how this helps/conflicts with
 >     the projects in planning for user account control and user account
 >     management?  Has the project team gotten that team's agreement?
 >

I would expect Glenn's participation in the open security-discuss review 
of the initial proposal to count as a reply to the first question, and 
both that open discussion and this case as the check for conflicts with 
any other projects.

 >> The substitutable tokens are:
 >
 >>      4.11. Security Impact:
 >>     It's a PAM module that would get added to the default stacks
 >> (snippets).
 >>
 >>      4.12. Dependencies:
 >>     As this module would be listed in PAM snippets it relies on PSARC
 >> 2005/275 Per-user PAM configuration.
 >>     If PSARC 2005/275 does not integrate this project would update
 >> pam.conf instead.
 >
 >     Is this case or isn't it dependent on 2005/275?  What exactly are
 >     the proposed snippet and/or pam.conf changes?  Will they be
 >     applied by default in a Patch release binding?
 >

It is not a dependency as such: we basically intend to play nice with 
whatever the appropriate PAM configuration mechanism is: if 2005/275 is 
integrated that means we add the module to the appropriate snippet, 
otherwise we edit pam.conf.

The PAM configuration change is the addition of this module to the 
"other" account stack.

 >> Standards, Environments, and Macros                   pam_auths(5)
 >
 >>      The argument to auths is a comma-separated list of authorization
 >>      names chosen from those names defined in the auth_attr(4)
 >>      database. Wildcards may be specified as well as substitution
 >>      tokens, described below.  Any one authorization listed is
 >>      sufficient to be granted access.
 >>
 >>      The argument to policy_profile is the name of a single policy
 >>      profile as defined in prof_attr(4). Any authorization in the
 >>      profile (or in an included profile) is sufficient to be granted
 >>      access. In the profile name no wildcards may be specified,
 >>      though substitution tokens can be used.
 >>      Authorization names listed in the profile can contain
 >>      substitution tokens and the wildcard symbol, as though they were
 >>      specified as an argument to the auths option.
 >
 >     This could/should be clarified to ensure that it is understood
 >     that the appropriate solaris.login authorization is needed as well
 >     as one of the explicit authorizations.

Ok. The documentation will be updated to reflect this.

 >>      Example 5 Requiring Multiple Authorizations
 >>
 >>
 >>     other account required pam_auths.so.1
 >> auths=com.xyzcompany.access.server
 >>     other account required pam_auths.so.1
 >> auths=com.xyzcompany.access.dmz,com.xyzcompany.access.sensitive
 >>     other account required pam_auths.so.1
 >> auths=com.xyzcompany.access.dns
 >>
 >>      These entries would require anyone logging in to have been
 >>      granted three authorizations: com.xyzcompany.access.server,
 >>      com.xyzcompany.access.dns and
 >>      either com.xyzcompany.access.dmz or
 >>      com.xyzcompany.access.sensitive.
 >
 >     Isn't it really four?  One of solaris.login and these three.

It is. Good catch. The docs will be updated.

Bart