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

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



> 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

I think you're referring to my patches here, even though I don't
have many/enough pam_overwrite()'s in there.  (The way _pam_md() is
defined doesn't let me clean up the crypt(3) output buffer without
the risk to SEGV of a write to a read-only location, for example.)

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

You're missing the point behind these cleanups.  It is acceptable
that we have sensitive information in the address space _before_
pam_end() is called.  We want to achieve that this information isn't
left around _after_ pam_end().

Let's use a network service as an example.  The service, such as
FTP or POP3, may require that users authenticate to it first.  This
is where PAM is involved.  However, most of the code implementing
that service is only reached after authentication.  This is also the
code that handles the most untrusted data (mailbox contents in the
case of POP3, "/incoming" directories in the case of FTP).  It is
desireable that vulnerabilities in those parts of the service can't
reveal the sensitive data that was used during the authentication.

> 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 protection against a maliciously-written application, --
this would be impossible for reasons other than those you mentioned.
This is meant to protect against an application that may "leak" its
privileges to an attacker at a later stage.

Signed,
Solar Designer





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