On 10/07/08 18:32, Nicolas Williams wrote:
> On Tue, Oct 07, 2008 at 10:53:32AM -0500, Nicolas Williams wrote:
>>> One of the main reasons we choose to have the configuration available as
>>> module options rather than in some config file was to allow for multiple
>>> different stacks to have a completely different use of pam_authorized
>>> and to allow multiple pam_authorized entries with a different config in
>>> multiple places in the same stack.
>> I understand. Adding a service name token to the profile name solves
>> that problem.
>
> OTOH, this falls down if you end up combining pam_user_policy with
> pam_authorized and expect to have different profiles for pam_authorized
> according to {PAM_SERVICE, PAM conf file where pam_authorized invoked},
> as we don't track the latter.
>
> I'm not sure how important that is. But it'd be good to have an answer
> for that, and at the moment I don't.
Now, the goal is to avoid the need to deal with modified pam.conf or
equivalent files when upgrading a system (or patching or similar).
The easiest way to go about that seems fairly simple:
- we ship a pam.conf that contains a binding entry with pam_user_policy
and a second binding entry with pam_system_policy and nothing more
- the first module looks for whatever file in /usr/lib/security it's
being pointed to if the appropriate pam_policy exists in the user's
attributes or profiles, in its absence it returns PAM_IGNORE
- the second module looks for whatever file in /usr/lib/security that is
specified in host_attr(4) for the local host. If this is absent it falls
back to "any.conf" (or some other sensible default)
Editing pam.conf or any of the files we ship in /usr/lib/security is not
supported, and upgrading/patching/... will either overwrite them or
complain (whatever the packaging system does in such cases), but it
won't merge or modify the file contents.
If someone wants to specify a local PAM stack one needs to walk through
for accessing this system a simple change to host_attr(4)'s pam_policy
to point it to a locally created and customised file would do.
That file can then contain a pam_authorized.so.1 entry that points to a
policy profile (containing the authorizations needed) with policy=, or a
list of acceptable authorizations with auths=.
A policy profile can be stored in prof_attr(4) but would be marked as
being different from a rights profile (a.k.a. execution profile) as it
has a different interpretation and is meant to be applied to a host or
passed as argument to pam_authorized (thus allowing admin tools from
showing them in the appropriate manner): e.g. in such a policy profile
"auths=" indicate that /any/ of the authorizations listed are sufficient
(while in a rights profile /all/ of the authorizations are granted).
Some additional keywords could also be provided (specifically for
pam_authorized, but other uses will no doubt appear -- for example to
replace policy.conf by a set of key=value pairs), so that the three
different cases for logins can be handled:
"login_auths_local="
"login_auths_remote="
"login_auths_console="
where authorizations can be specified that would be checked for by
pam_authorized.so.1 in addition to one of the authorizations from auths=
for respectively local logins, remote logins and logins on the console.
These options could thus be used to make pam_authorized.so.1
check for authorizations other than solaris.login.{local,remote,console}.
Having unmodifiable pam.conf and friends solves the no-editing problem
for any module, not just for pam_authorized, as modifying the local
policy requires creating a local file (which we thus won't touch) and
updating a single field in host_attr(4) (a field we won't touch and as
it's a key=value pair it's easy enough to avoid even if we need to add
or modify other key=value pairs for that entry).
As long as host_attr(4) is not yet implemented it could be reasonable to
have a PAM_POLICY= in policy.conf, which would be used by pam_system_policy.
Bart
