Controlling PAM modules

[Ivan Grover]

Thanks Jason.

Let me try to explain the complete problem:
I have three authentication modules
-- pam_radius_auth.so (for remote authentication)
-- pam_unix ( unix local authentication)
-- pam_opie (challenge/response)
and other accounting modules such as pam_abl.

I would like to place these in my service conf file in a best possible way.

Assume my service conf file looks like:
auth required pam_env.so
auth required pam_abl.so config=/etc/security/pam_abl.conf
auth sufficient pam_radius_auth.so // for remote authentication
auth required pam_unix.so
auth required pam_opie.so // for challenge response

User will try with Remote authentication, if it fails then he has to enter
correct unix passwd and challenge/response(providing both might be painful
sometimes).

Please advise if the above doesnt look ok or if i missed something.



PAM application can be configured in the following way:
- setup doesnt want to use Remote authenticaion, then pam_radius_auth.so is
unneccessarly executed. so disable it
- setup doesnt want to use user lockouts/ip address lockouts, then
pam_abl.so is unnecessary. Similarly challenge/response softwatre may not be
there in client side, so doesnt want to run pam_opie.so. so disable both in
this case.

By allowing such configurations, i might have to keep so many service conf
files for each configuration. instead can i have some other better approach
, if any.

Does it make sense to leave to SecurityAdministrator to configure in the
desired way or we try to code the PAM modules in a proper way so that they
dont crash if they dont find the setup required.


Please let me know your comments.

On Wed, Sep 17, 2008 at 6:16 PM, <freebsd-security at dfmm.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>  Do i have any standard way to skip one of the PAM module
>> with out changing the service conf file.
>>
>
> Why do you not want to change the per-service conf files?  Those files
> _are_ the database.


>
> There are a bunch of strategies that you could use to, e.g., maintain your
> alterations as a diff to the base-system config so to make upgrades easier,
> but a) to answer your question, no, there's nothing standard for that, and
> b) that is an especially risky approach - you could completely break your
> security, letting anyone in, or locking legitimate users out, etc.
>
>
>  -Jason
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (FreeBSD)
> Comment: See https://private.idealab.com/public/jason/jason.gpg
>
> iD8DBQFI0PwqswXMWWtptckRAqLsAJ9taCFEPfVGwY6Rrt3qtLuHVvmNDwCfatyl
> S++ho4Gf4Zl/3E6Vjkks26o=
> =gGZG
> -----END PGP SIGNATURE-----
>