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

Re: bunch of questions: pam_unix implementation... (long)

Andrew Morgan wrote:
> "Michael Ju. Tokarev" wrote:
> > 4.a. why current pam_unix uses "strange" method of "storing" password
> > afetr a user prompt?  Here is a simplified code:
> >
> >   pam_converse(..., &resp, ...);
> >   pass = strdup(resp[0].resp);
> >   pam_drop_reply(resp);
> I think this was intended (one late night) as a paranoia thing. The
> intention was to explicitly break the link between any dangling pointer
> reference in some state that the application (conversation function)
> might have, to the current location of the password. The reasoning being
> that it is easier to audit a module's use of a password if you know
> there are no other references to the memory it is stored in (outside the
> module and by extension the libc it uses for something like strdup()).
> That was the intention at least, hindsight and years later, it looks a
> little optimistic.

The funny thing about all that stuff together with pam_overwrite() et al
in many places (and in Steve's (non-public) patches for pwdb) is that
anyway password(s) are in pam items during all the time between
pam_start (after auth, when pam_set_item(AUTHTOK) called) and pam_end.
Thus, password is accessible, and that "protection" (declaring
PAM_[OLD]AUTHTOK in the file that should not be included by app)
is just like a joke.  Numbers for that #defines are "standard",
so that file is not needed.  Moreover, that authtok comes from
application itself as an answer to conversation function, so
app have it "in the first place".  Doh!
This is not to say that all that care with pam_overwtite etc is
not necessary -- the less places that "knows" the password will be,
the less chances to use it.  Maybe in some future time authtoks
will be stored in some other safe place (like signing log records
in modern syslog-ng -- who taked care of that 10 years ago?!) that
will be unaccessible to app... :)

But I see the point here (around my original question), and I
already realized that myself.  Thanks for info anyway.


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