Darren and Bart,
I like this idea. I have a few comments about the authorization
specification. The man page states:
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. Any one authorization listed is sufficient to be
granted access.
The term "wildcard" has previously referred to the * that matches any
corresponding components after the dot. However, here the term seems to
apply to substitutions resulting from expanded variables. Since I assume
that * is not allowed, some better term like:
Embedded variables may be specified, and are expanded before making each
authorization check.
As you know, chkauthattr(3TSOL) check a single explicit authorization,
and isn't particular efficient with respect to lookups.
It is ironic that your proposal supports reverse order names. The
original proposal I submitted to PSARC has all of the Solaris
authorizations start with com.sun, but we were forced to use solaris,
instead. I guess that is a good thing now, since none of our existing
authorizations will match a hostname on SWAN.
Does the reverse ordered authorization require a hostname match, or can
it just match a domain?
This last feature doesn't appear to scale very well.
--Glenn
Darren J Moffat wrote:
> We were thinking that it would make sense to add a pam module that would
> permit controlling access to the system based on authorizations; it
> seems to be the type of thing that fits in nicely in the authorization
> model.
>
> There's already a basic authorization (solaris.login.remote) that has
> been used to control logins over the network on Trusted Solaris, so the
> basic configuration of such a PAM module could check for that
> authorization.
>
> We were thinking that adding solaris.login.local (a non-remote login
> that's not on the console) and solaris.login.console (when it is the
> console) would make sense.
>
> All three authorizations would be added to the Basic Solaris User
> profile, so that a default configuration with pam_authorized.so.1 in the
> stack wouldn't change anything for normal users.
>
> Additional authorizations could be required by specifying them as an
> option to the module, so that it becomes possible to require a host- or
> domain-specific authorization to gain access to a system.
>
> We've enclosed a manpage of what the module would look like.
>
> Comments and thoughts welcome.
>
> --
> Bart Blanquart & Darren Moffat
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
