https://bugs.kde.org/show_bug.cgi?id=481808
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #40 from [email protected] --- (In reply to nyanpasu64 from comment #37) > Created attachment 195054 [details] > /etc/pam.d/kde modified to not trigger faillock on sleep-wake > > According to https://wpollock.com/AUnix2/PAM-Help.htm#advanced, we can > recognize specific return codes (like AUTHTOK_ERR) and take specific > actions, like "die" to avoid running subsequent faillock. I've prototyped an > alternative /etc/pam.d/kde that appears to *work*! (no entries in faillock > CLI after sleep and wake, and no "Unlocking failed" message): > auth [success=1 authtok_err=die default=bad] pam_unix.so > try_first_pass nullok > > Note that authtok_err needs to be lowercase (unlike the above site), or else > even the right password doesn't succeed. > > I've attached my full modified kde file (made by inlining system-login and > system-auth into the file, and editing the innermost system-auth commands). > I'm not sure if these files could change in PAM updates or between > distros/versions, and our KDE authentication chain would no longer work > properly in that context. > > Does anyone know if *not* triggering faillock upon the authtok_err return > code could have any security implications? When I entered the wrong password > on purpose, I still found an entry when running faillock in a terminal. Definitely seems like a decent bandaid work around, but wouldn't consider this a long term fix. You're essentially just not logging the failure instead of actually preventing the failure from happening in the first place. From a security perspective, although the risk is likely small, you're losing brute force protection where someone/something malicious is leveraging an authentication token manipulation that results in an error. While this isn't the same as a straight up invalid password attempt, those malicious manipulation attempts would continue to happen silently, which is obviously not ideal. -- You are receiving this mail because: You are watching all bug changes.
