https://bugs.kde.org/show_bug.cgi?id=481808
--- Comment #44 from [email protected] --- (In reply to nyanpasu64 from comment #41) > My view is that "malicious manipulation attempts" are indistinguishable from > sleeping KDE's lock screen, and would provide no system access or leaked > bits (about the password being correct or not) to an attacker to the kde PAM > service. Moreover it would not apply to regular system logins or sudo, > because I separated the KDE service from the standard system ones it > previously inherited from. Unless there's some way to guess a password and > return PAM_AUTHTOK_ERR *if* it's incorrect? > > Is it possible an attacker could use the kde service in a > *non-kscreenlocker* process to brute-force your password without rate > limiting? Maybe, but they could do the same thing with unix_chkpwd directly > (which logs if incorrect). > > Can you call pam_end() within a conversation? My gut instinct is no (it > could cause state corruption and/or use-after-free), but I have not tested > it... > > In any case, if this is not an acceptable solution, I suppose the remaining > option is to not initiate a pam_authenticate() transaction until the user > submits a password. Rewriting kscreenlocker_greet to do this is above my pay > grade... I think your points are all fair, which is why I stated the risk is likely small. I think the crux of my comment still stands though that this should only be considered a "bandaid". You're not solving the problem, you're alleviating a symptom of it by preventing an erroneous lockout of the account. -- You are receiving this mail because: You are watching all bug changes.
