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.
I like the basic idea. Here's a possible side effect to consider.
You've said that regular users would have all three authorizations by
default (to match the current system behavior), and additionally root
has all authorizations (solaris.*) explicitly granted. However, it's
also true that a default system disallows root console and remote
logins, using specific configuration file entries for login and sshd.
I recognize that those mechanisms to disable root logins would continue
to work after implementing your proposal. However, it would interfere
with two goals we might have for future evolution, namely:
(a) A unified control mechanism, like the authorizations you propose,
should someday replace the settings in service-specific config files to
control root logins.
(b) The root account should continue to have a simple set of
authorizations, like solaris.*, not a long enumeration of auths that
excludes solaris.login.console and solaris.login.remote.
Meeting those two goals would be difficult unless we introduce a
subtractive model for specifying authorizations like we have for
privilege sets. Is that the best solution? Or is there any way to recast
this proposal to make this future evolution easier?
Scott
