bug: i3lock accepts any password

[decaby7e]

I'm submitting a…

[-] Bug
[ ] Feature Request
[ ] Other (Please describe in detail)

Current Behavior

i3lock will accept any password.

Expected Behavior

i3lock should not accept any password, but only the correct one.

Reproduction Instructions

Not sure how to reproduce at the moment but running i3lock i3lock: version 2.11.1 on Ubuntu 20.04.

Environment

Output of i3lock --version:

i3lock version: i3lock: version 2.11.1 © 2010 Michael Stapelberg

[Airblader]

This issue is not actionable at the moment. Can you please describe how you are executing i3lock, what exactly you do, what you see etc? I think either it never squires the lock (and exits when giving up), or crashes, but I doubt that it really accepts any password (we don't even manage the authentication part—pam does this).

[stapelberg]

My first guess is that this is the same issue as #311, i.e. i3lock isn’t correctly set up. Can you set up i3lock as explained in 2ab9a39 and see if that fixes your issue?

Also please let us know how you have set up i3lock. Is it via a systemd service unit?

[decaby7e]

Currently activating it manually via the following i3 keybinding:

bindsym $mod+l exec i3lock

I found the following error in /var/log/syslog, which is definitely related to some MFA stuff I've been messing with recently:

Apr 22 12:44:38 <hostname> i3lock: Couldn't open /etc/duo/pam_duo.conf: No such file or directory

So it seems it was caused by my PAM stack being improperly configured, as the bug went away after fixing my PAM stack.

Is it still expected for i3lock to accept any password, even if PAM is misconfigured like this?

[stapelberg]

Can you describe how exactly your pam stack was misconfigured and how you fixed it?

It might be good to make i3lock resilient to this misconfiguration, if possible.

[decaby7e]

This is a diff of the fix I made to /etc/pam.d/common-auth

17,19c17,18
< auth	[success=1  default=ignore]      pam_unix.so nullok
< auth    [success=ok default=ignore]      pam_sss.so use_first_pass
< auth    [success=1  default=ignore]      /lib64/security/pam_duo.so
---
> auth	[success=2 default=ignore]	pam_unix.so nullok
> auth	[success=1 default=ignore]	pam_sss.so use_first_pass

The configuration for pam_duo was removed at some point, so I just removed the module for now. I'd be happy to provide additional information/testing to help in fixing this.

[stapelberg]

I cannot reproduce this problem. When I add your auth [success=1 default=ignore] /lib64/security/pam_duo.so line after my pam_unix.so line, I just get an authentication failure from PAM, but i3lock never unlocks.

Can you provide all the files in your /etc/pam.d, both working and non-working, ideally as a tarball each?

[decaby7e]

Here is the full contents of my /etc/pam.d/

pam.d.tar.gz

[stapelberg]

Thanks for the full configuration.

I was able to reproduce the problem, but only after installing pam_duo.

In my syslog, I see:

Apr 24 12:00:18 x1x unix_chkpwd[20416]: password check failed for user (michael)
Apr 24 12:00:18 x1x i3lock[20413]: pam_unix(i3lock:auth): authentication failure; logname=michael uid=1000 euid=1000 tty=:0 ruser= rhost=  user=michael
Apr 24 12:00:18 x1x i3lock[20413]: Couldn't open /etc/pam_duo.conf: Permission denied

In the pam_duo source code, I see:

    i = duo_parse_config(config, __ini_handler, &cfg);
    if (i == -2) {
        duo_syslog(LOG_ERR, "%s must be readable only by user 'root'",
            config);
        return (cfg.failmode == DUO_FAIL_SAFE ? PAM_SUCCESS : PAM_SERVICE_ERR);
    } else if (i == -1) {
        duo_syslog(LOG_ERR, "Couldn't open %s: %s",
            config, strerror(errno));
        return (cfg.failmode == DUO_FAIL_SAFE ? PAM_SUCCESS : PAM_SERVICE_ERR);

failmode defaults to safe, which means that pam_duo will report success when it fails!

Now, in your pam.d config file, you configured pam_duo as:

auth    [success=1  default=ignore]      pam_unix.so nullok
auth    [success=ok default=ignore]      pam_sss.so use_first_pass
auth    [success=1  default=ignore]      /lib64/security/pam_duo.so
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so

The problem is that with success=1, you say that when pam_duo succeeds (which it does when its config file is missing!), pam should skip over the next line (pam_deny), which explains why you can login with any password.

This misconfiguration happens entirely within PAM, and i3lock has nothing to do with it.

If you want to prevent others from running into the same issue, my recommendation is:

• Convince the pam_duo folks to provide instructions on how to configure PAM in a safe way. Currently, it seems like they don’t provide any example configuration, at least not within the tarball I downloaded.
• Convince the pam_duo folks to change the failmode away from safe.

[decaby7e]

It turns out there is an option given here that allows the failmode to be switched to "secure". Though this is not configurable if the configuration is missing, so that's a bit useless. Not sure that "safe" is the best default action...

Thank you for the help with this anyways, glad to hear i3lock was not the culprit!