[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM concepts (was: pam_{unix,pwdb}: crypt/md5 necessary?)

> But: if I looks to some more-or-less "big" modules, I see so many
> strange things...  I just don't understand: why people written this
> stuff this way.  It is _very_ hard to support/enhance/change/debug
> some existing modules...  I fell sometimes that this is just badly
> written code, without any (good) concepts at basis. Ok, this need
> explanation, and it is rather big.  Let's try to explain.

Yes, most existing PAM modules are badly written.  Fortunately, only
a few are needed on a given system, so you can start re-coding them,
and have something usable for you within a reasonable time.

> pam_{unix,pwdb} modules.

I think that both need to be thrown away and a new one developed to
replace them.  Same functionality, twice smaller, cleaner code.

For now, I've just hacked pam_pwdb making it twice smaller for me,
but that's only a temporary solution.

> Why two of them with more-or-less similar functionality?  Unixes
> now have some sort of nsswitch -- so -- why the pwdb just comes in
> not utilizing the features of plain getpwnam() & Co!?  The idea was

You'd need to re-implement the password aging checks so that they
don't utilize libpwdb (which is now obsolete, but widely used).

> so simple -- use existing interface, that's all... Yes, there are
> some systems that have no nsswitch magic, maybe this was issue?

We didn't have that on Linux until glibc 2.1, as well (and I'm not
sure the glibc 2.1 code is so good, but that's a separate topic).

> Okay, let's see pam_unix.  It uses generic getpwnam/getspnam interface,
> and it have no knowledge about actual source of information this routines
> returns (this stated in comments there).  So -- and this is conceptual
> question -- why it should deal with password stack at all?  It will be
> unusable if nsswitch will point to ldap for example...  Why not just
> drop password stuff from it and implement some little modules for each
> king of real data storage (passwd+shadow, nis, ldap, etc), and _only_
> password, leaving other (account, auth, session) basic things to pam_unix?

I don't yet have an opinion on this, but what you're saying sounds

> Ok, let's see next thing.  Asking new password.  Why pam_unix, pam_pwdb
> attempted to ask new password in their passwd routines?  Why in this

This has been answered here already: because pam_cracklib and such
didn't exist at the time and are meant to be optional now.

> case pam_cracklib?  Remember the previous statement -- many little
> "storing" modules? -- in this respect, there should be definitely one
> "asking" module like cracklib, and "storing" modules should just store

You could have pam_{pwdb,unix} ask for the new password and "storing"
modules stacked after it to store the password.

> PAM_AUTHTOK, not asking one...  Cracklib does a good job in enshuring
> password quality, and there is no need to duplicate this many times.

CrackLib was good, but is a bit outdated nowadays.  pam_cracklib is
trying to fix some of this (but fails in a number of ways) by adding
extra checks.  So we have password quality checks in both CrackLib
and pam_cracklib.

One of the first things I did when starting to use PAM on my systems
(BTW, just a few months ago) was replace CrackLib+pam_cracklib with a
module of my own based on the password/passphrase quality checks and
random passwords support code I was using in my shadow-kit patches.
While the entire thing is getting linked into one *.so, the password
checks are modular enough to be easily used without PAM as well.  I'm
going to release this sometime in September.

> Again, "password asking".  One good thing that can do pam_unix is to
> enshure that new password is not the same as one of previous ones
> (remember=XXX).  Really good thing.  But -- where those old passwords

This is really a questionable feature.  It can both improve and hurt
security.  I haven't implemented it in my pam_passwdqc, yet (am only
checking against the current password, which is always known).

> Look also to pam_unix_passwd.c.  Salt manipulation is a great place!..
> I see two macros:
>   #define ascii_to_bin(c) ((c)>='a'?(c-59):(c)>='A'?((c)-53):(c)-'.')
>   #define bin_to_ascii(c) ((c)>=38?((c)-38+'a'):(c)>=12?((c)-12+'A'):(c)+'.')
> and a big crappy routine:

All this crap is inside an "#if 0" on my systems.  The same goes for
the password hashing code, which should be in libc/libcrypt only.

> Compare also salt generation in 'crypt' and 'md5' ways...

I've put crypt_gensalt() into libcrypt for that, which permits for
adding new password hashing algorithms without touching PAM at all.

> At this point I have another question.  After some more nights, I will have new module
> (call it pam_unix3, if you like) that is not a pam_unix but does exactly the same
> (and plus some more, and maybe minus password changing stuff).  This will _not_ be
> a patch, since it is basically a complete rewrite.  So, -- what to do with this!? :)

Give me a copy. :-)

# $Id: passwd.pam,v 1.1 2000/07/16 14:09:05 solar Exp $
auth       required     /lib/security/pam_pwdb.so shadow nullok
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_passwdqc.so min=99,24,12,8,7 max=40 passphrase=3 match=4 similar=deny random=42 enforce=everyone retry=3
password   required     /lib/security/pam_pwdb.so use_authtok shadow prefix=$2a$ count=8
session    required     /lib/security/pam_deny.so

Solar Designer

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []