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

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



Ok.  I see three responces for now.
Solar Dessigner did/does almost the same thing as I am here --
just throwing away some code and reimplementing it on it's own. :)
Others (Nalin Dahyabhai and Steve Langasek) want not to see
replaces/rewrites...  And both sides arguable enouth.  Wow! :)))
But I see that I hit something painy...

Ok, this is a reply to three replies at once.

About thowing away password asking from pam_unix et al.

Steve:
> Some people don't want to use pam_cracklib on their machines, and they
> shouldn't be required to do so.  If pam_cracklib is /required/, then you don't
> really have modularity, do you?  Hence, all pam password modules are able to
> prompt for the new password, so that they can be stacked however the
> administrator chooses.
> 
[pam_cracklib have problems]
> 
> I think that modularity, in this case, means writing modules which are wholly
> independent of one another.  PAM modules should interoperate nicely, but no
> PAM module should depend on other modules to do its job.

We have many useful modules.  If we also have one (or more) good (simple) password-asking
module, this will not be an issue.  Recall that problems with RedHat paths
to cracklib dicts exists in _unix and _pwdb also.  If you won't use cracklib, --
viola, another simple module can be used for this.  This can also be implemented
by having simple config file for "pam_askpass" and pam_cracklib with system-wide
defaults so there will be no need to edit each file in /etc/pam.d.  Again, with
pam_stack it is not an issue.  I think that _reasonable_ dependences between
modules are ok.  If one module requires pam_cracklib, it is bad.  But if one
requires _any_ "asking" module of your taste, it is ok.  Well, we at least
should place some module for each stack of login service for example.  Think
as about having just one more "stack" -- "password_ask".  Password stack is
useless for login if there is no modules in auth stack!
Yes, each module can ask of it's own.  I think that this is just a waste of
efforts (and having use_authtok in /etc/pam.d/* after pam_unix is ugly),
and cause more incompatibilities (prompts are not standartized etc) as you
see in pam_cracklib itself.

Steve:
> Michael:
> > And, -- yes, this new module will have _no_ security history at all unlike
> > current pam_unix and pam_pwdb that already in production.
> 
> pam_unix is a fairly mature module now.  By writing from scratch, you also
> lose that, and it becomes difficult to see if your module is always doing the
> Right Thing.
> 
> I think we would benefit more by just cleaning up the pam_unix we have, if
> there are problems with it.  It's already used by a great number of people,
> and we know it works well.  Breaking with that history means going through the
> beta testing phase all over again.

Solar:
> > 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.

This two statements looks nicely agains each other.. :)

This is a big issue.  Not only with pam_unix, but with other modules too.
And I really does not have an answer -- things _should_ be changed, but how?
(_should_ -- also questionable?  Maybe just forget about all the stuff that I
ask here, the same way as I thowed away my attempts to "patch" pam_cracklib
some time ago...  It is also an acceptable solution... )

The strangest to me thing in open source world is that many people implemented
the same things for "its own" without collaboration.  This problem is far
wider.  Many packages written so far have it's own (bad most of the time)
implementations of functionality that already implemented in other places.
Consider for example:
  samba -- charset conversation/classification.  There are iconv and locale
    already.  Both implemented well (almost?) in glibc.  Maybe implemented
    reasonably well on BSD.  Others?  -- samba does not use any of this,
    have own implementation, and now samba team have troubles implementing
    unicode conversations.  Already implemented elsewhere...
  gnupg, sasl -- uses own crypto implementation.  OpenSSL/SSLey? (for crypto,
    there is another story -- legacity...).  This was my question that started
    this tread -- look to subject...
  one funny place -- linux kernel.  3 (three!) copies of zlib!  Each hacked/changed
    of its own...
  etc etc.

There are many times where parts of software should be reusable...
But this is something like lirycs... :)

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

Clean concepts? :)

Steve:
> > 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).

I think it should be available.  When password aging used, it will stop
changing password twice -- first to "fake" one and second to old one.
(I know about minchange also).  From your statement, password aging is also
questionable.
I see no hurting here, since old password should be stored in encrypted form,
with the same attention as "current" ones.
Again, such a feature should be configurable (remember=0 -- and voila! :)

Nalin:
[where old passwords should be stored]
> If you're using a networked authentication system, then this is policy,
> and as such I really think it should belong on the server.  This means
> it is not PAM's problem to solve.

Yes, it should belong to the server.  But who should store them there?
And who should check new password against them?  I think that this is
pam_ldap, pam_nis, pam_nisplis, pam_other_net_system' thing, and, as such,
pam_files also.  And hence my original question -- how "asking" modules
should iteract with this?  If pam_{ldap,nis,...} itself "asking", thaer is
no issue.  And this is an argument against my "proposal" of separating
"askers" and "storers".


------------------
And some issues to concretic statements about code.

Steve:
> Michael Tokarev:
> > Pam_unix_auth.c.
> []
> > things in AUTH_RETURN only once.
>
> > This will clean things a lot since we will have no hidden side-effects in
> > macros. Thus, less choice to do a mistake...
>
> Have you found hidden side-effects in this code?

No.  But I don't mean here that this code contains bugs.  I just mean that
using this style of writing, it is just easier to make bugs.  And harder
to find/patch them and enhance things, and read it (and it will be just bigger
in compiled form, but this is not "critical").  This was an example of how to
not to write new code.  Maybe it is bad example -- this is just my opinion.
Pam_cracklib contains more examples of really crapy code, and as I see, all
here agree with this.

Steve:
> Michael:
> > This is a big pease of code with a lot of set[reug]id's (that logic I can't
> > even understand...)
> 
> The calls are necessary because glibc's NIS+ nsswitch module won't let a
> program see the password field for any user other than the one which matches
> the program's euid.  Because we don't know what permissions the program will
...
Ok, I just don't understand _what_ it does. :)  Why it does it is not a question.
But it is not a real question here.

> > Let's see how many times pam_unix does shadow (spwd) "retrieving".

This all was about that big piece of code for support for nis/etc with set[...]uid.
I point here not about efficiency, but again "easity" to made bugs/etc.
If someday linux will have another requirements for nis/etc calls, you will
need to change the same thing many times ;).  There are already some questions about
porting this stuff to other systems -- the same thing.  Again, just an example
of what _not_ to do in the future.

Efficiency also concerned here, too.  What I did in my (re)implementation
is to define one routine (pam_unix_init()) that accepts a flags and fills in
(retrieves) all passwd/shadow stuff if needed, storing it in one structure
and setting flags if say shadow entry unavailable.  This approach is a bit
more risky, since retrieved shadow entry not dropped immediately.  But it is
in memory anyway, since getspnam() uses stdio for this...
But you can control this (a bit tricky) retrieving of shadow info in _one_
place!

Little side note.  I see Steve are fun of pam_unix... :) (smile!) Authors? :)

Let me skip other coding issues, ok?  This all is irrelevant on what to do.
I recall that I won't blame someone, just wanted to understand, and argue
my positions....

------------
Ok.  Conclusion? :)

I'll try to finish reimplementation of pam_unix (without password changin
as of yet), and also will wrote pam_passwd_files and pam_passwd_nis to just _store_
passwords (maybe will look to pam_ldap also), with identical interface.  And will
write very little "asking" module, this is very easily.  With this, pam_cracklib
and similar (as of Solar's one) can be written/used.
I'll try to write all this with extreme care (I really understand the role PAM
plays in system's life).  No guarantee.  But I will try.  Maybe I will able to
do something useful, and at least people here can try to look to things...
I can propose some routines for migration, or, alternativaly, and may be better,
will reimplement pam_unix with it _complete_ today's functionality.
And let's see what position is right...  At least one will have a chioce.

But for the last -- how to _name_ this new pam_unix? :)  So that it will not collide
with existing one?  pam_unix2 (or 3 or any digit) does not looks well :)
Pam_nsswitch? :^)

And, -- can anyone point me to the SuSe implementation of pam_unix?
Or, better, maybe someone from Suse who have deal with suse's pam_unix reading this?

Regards,
  Michael.



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