[OpenAFS-devel] [PATCH]: Some modifications to the pam module (2)

[Ulrich Hahn]

I think this issue needs more attention:

On Thu, 29 Mar 2001 jacobi@de.ibm.com wrote:

> Ok, I have some new ideas concerning the AFS pam module. Last month
> I introduced the "trust_root" and "catch_su" options to the authenticatio=
n.
> I rethought the whole thing because I was still not satisfied with those
> options.
> So far the module is prompting every user for a password (except root),
> even if she is not registered in the current AFS cell.
> Now I included "pr" calls to ask for the existence of the user first
> (actually the
> module does the same like "ptr examine"). When the user is registered in
> the cell
> she will be prompted for the AFS password the usual way. Otherwise the
> module
> returns success, so that another pam module has to block/grant the user
> (from) authentication.

This adds little comfort, and hiting <return> once is not to much effort.

> This behaviour can be turned on using the new "trust_unknown_user" switch=
=2E
> A pam config may look like this:
>
> auth required  /lib/security/pam_unix.so      nullok md5 ....
> auth required  /lib/security/pam_afs.so.1     try_first_pass
> trust_unknown_user

This setup will raise difficulties for afs-only users (no local account
at all), as they will be asked for a lokal password that does not exist.

Most setups will use the afs pam module first:
  auth sufficient /lib/security/pam_afs.so.1  try_first_pass ignore_root
  auth required   /lib/security/pam_unix.so   nullok md5 ...

If you want further auth modules to be executed the sufficient
control-flag may be replaced with required.
This setup grants afs-only users system access and an afs token, local
users (except root) will still be asked for an AFS password.

If now a patch to afs_auth.c is supplied to check if the user exists in
the cell we don=B4t even need an additional argument (trust_unknown_user).
If afs_auth.c returns PAM_USER_UNKNOWN or PAM_AUTHINFO_UNAVAIL the user
will be prompted for the unix password.

> Thus, the admin can still create local users who are not known to the AFS
> cell but
> should have access to the machine. The "trust_unknown_user" switch makes
> "trust_root" and "catch_su" obsolete, and I think this is the right way t=
o
> evaluate whether
> to prompt for an AFS password or not. Hopefully, nobody but me used those
> to
> switches that are removed by my new patch ... 8-\

see above

> In case AFS is not available only root is granted login access. From my
> point of view
> this is necessary in order not to lock out the sys admins if the network =
is
> down (you can
> believe me this was a very painful experience for me 8-( ) on the one han=
d,

With pam_afs in first place and ignore_root set, root will allways get a
prompt. this way no network resources are accessed.

> but on the
> other hand it should not be possible to break in a system by blocking a
> service (i.e.
> make AFS unavailable to make the pam_afs module grant access without
> prompting
> for a password (for example by pulling the network cable out of the wall
> plug)). I still
> have in mind giving users null passwords locally and having them type in
> the
> AFS password for a login.

Local password files may not have null passwords (use :*: for afs only
users). This works very well in our setup.

> Does somebody have any further ideas/suggestions? Here is the patch ...
>
> Carsten Jacobi
>
> (See attached file: openafs-1.0.3-pam_trust_unknown.patch)
>

: Ulrich Hahn                 email: ulrich.hahn@zdv.uni-tuebingen.de :
: Zentrum f=FCr Datenverarbeitung            Tel: + (49) 07071 29 70315 :
: Universit=E4t T=FCbingen                     FAX: + (49) 07071 29  5912 :
-----------------------------------------------------------------------