> 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
