Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Controlling PAM modules

From: Ivan Grover (ivangrvr299gmail.com)
Date: Wed Sep 17 2008 - 11:16:15 CDT

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

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-securitydfmm.org> wrote:

> 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
> Version: GnuPG v2.0.9 (FreeBSD)
> Comment: See https://private.idealab.com/public/jason/jason.gpg
> iD8DBQFI0PwqswXMWWtptckRAqLsAJ9taCFEPfVGwY6Rrt3qtLuHVvmNDwCfatyl
> S++ho4Gf4Zl/3E6Vjkks26o=
> =gGZG
freebsd-securityfreebsd.org mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribefreebsd.org"