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

[Gary Winiger]

> 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.

> 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()

> +----------------------------+-----------------------------------+
> | 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?

> 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.

> (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?

> 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?

> 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.

>      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.

Gary..