swaylock
swaylock copied to clipboard
swaywm
Support for other pam modules
Hi! I know this is low priority compared to the amazing work you're doing on moving sway to wlroots, but one of the things that'd hold me back from moving to sway is the lack of support for MFA on Swaylock. I use a yubikey as a second factor of authencication and TOTP (google auth) as a fallback in case I lose the yubikey. For some reason, it seems that neither scenarios are covered or supported by swaylock.
Anyway, thanks for the good work.
Cheers, Henry John Kupty
You can write whatever you want in /etc/pam.d/swaylock, it is standard pam so should do anything you ask it to (defaults to the 'login' ones so your setup might work out of the box if you have configured it globally; if you haven't it's just a file to change)
Here is my /etc/pam.d/swaylock:
auth required pam_unix.so
auth sufficient pam_yubico.so mode=challenge-response ...
auth required pam_google_authenticator.so
This exactly the same I have for my physlock and my sudo setups. Both of them act as I described:
I use a yubikey as a second factor of authencication and TOTP (google auth) as a fallback
What happens is that swaylock doesn't support any of those, as I described:
For some reason, it seems that neither scenarios are covered or supported by swaylock
In details, it fails with that pam setting, either if I have the yubikey plugged in (which would suffice since it is sufficient on this stage) or if it is supposed to prompt me for the TOTP code.
The thing is, it seems none of the following modules are called and it fails with the password. If I was mistyping my password, it'd fail after prompting me for the TOTP code, which is not happening.
Ah, right, totp requires displaying something so that'll need extra support, I didn't pay attention to the last bit. Challenge-response shouldn't need anything though; the yubico website says there's a debug mode so I suppose that might help you figure out what goes wrong...
Ok, so I figured out what happens with the yubikey. The challenge-response file is stored under /var/yubico accessible only by root. As described on their documentation:
sudo mkdir /var/yubico
sudo chown root.root /var/yubico
sudo chmod 700 /var/yubico
This means that only a process being run as root can check if the attached yubikey is the one that generated that response for that challenge.
Swaylock is installed as root, but is run as the user which calls it. It should have setUid bit set for it, in order to inherit root access and access yubikey. This is what physlock does.
Now, for TOTP, I'm not sure how that prompt would need to be implemented.
I'm not asking that. That is done by its pam module. The thing is, having pam to manage privilege access is a way to ensure setuid is secure. They're related on that end, otherwise swaylock is just a fancy screensaver that has no actual security over the machine, such as blocking tty.
The thing, in the end, is that if swaylock isn't run by root, it can't block that, so I can easily change the tty and pkill swaylock, which was exactly what I did when I got stuck by swaylock not being able to run the pam modules it should.
so I can easily change the tty and
pkill swaylock
Don't leave yourself logged in on other ttys, then? You still have to enter a password at getty unless you configure it to accept no password, in which case I can just reboot your computer and get in anyway.
Even so, swaylock doesn't have to be root to prevent tty switching. Sway can already do that.
so I can easily change the tty and pkill swaylock
You could also just kill sway directly.
Sway can already do that.
If that is the case, then it's buggy, because I've being swapping back and forth between a sway session to test this.
Even so, you're relying on 'swaylock users will have their ttys secure' to make sure swaylock is secure.
But we're diverging from the topic.
It'd be totally fine if you otherwise state that you don't support pam, but most pam modules require to actually be run as root. If you're breaking that invariant, then you're making most of pam security useless, thus not entirely supporting it.
Sway can do this, not that it does do it.
PAM works fine now without root. I'm not making it root.
You can do whatever you want, and I can also not use sway or swaylock.
It is disappointing that the it's stupid argument is played instead of pointing out reasons and real arguments.
physlock and slock does this and I've never seen a it's stupid card played against them, but anyway, what do I know, right?
Ahh, I almost forgot. You still have issues with google-authenticator though. But I'll leave that to anyone else interested in it.
I'll give sway another shot. I do believe in its potential, so the issue still remains - mfa support is missing from swaylock.
Even though there may be other ways to deal with dealing with challenge-response as in the yubikey - and I'll not discuss this for now - , there are other forms of mfa which might require another password to be typed and that is not supported by swaylock, which fails right after the password was correctly typed.
Patches welcome, but I haven't changed my mind about swaylock running as a normal user.
I'm not questioning the user running swaylock - though I'd appreciate a debate over the theme. Still, I think there should be a way to deal with MFA, which doesn't need to be a challenge-response to a third-party hardware.
I'll see what - and if - I can do.
Running swaylock as root is an incredibly stupid idea.
How else are you gonna authenticate against the system password on FreeBSD? There you must be root to do that, even with PAM.
To solve this problem in xsecurelock, I had to factor out the talking to PAM into a separate process (called authproto_pam there), so I can run PAM as setuid root, while having anything UI run as the calling user. Was annoying to implement, but still much better than what everyone else does (namely, run the entire screen lock as root).
swaylock can fork, drop root on the parent, and use the child to call getspnam, which works on FreeBSD. It then drops root and validates passwords over a pipe.
I don't want to complicate the root code here by introducing PAM to the equation. Right now it's small, isolated, and only has root for a short period of time. It's easily reasoned about and easily verified.
Yeah, that is the non PAM way though, and PAM is pretty important e.g. for 2FA stuff.
Of course, if you asked me this is a bug in PAM - shouldn't there be a way I make PAM open all file handles it needs, then drop privs? But there is none.
On Wed, Dec 12, 2018, 07:46 Drew DeVault <[email protected] wrote:
swaylock can fork, drop root on the parent, and use the child to call getspnam, which works on FreeBSD. It then drops root and validates passwords over a pipe.
I don't want to complicate the root code here by introducing PAM to the equation. Right now it's small, isolated, and only has root for a short period of time. It's easily reasoned about and easily verified.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/swaywm/sway/issues/1832#issuecomment-446575951, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPWsBd4gXh9u8jypX3uYUSCgKYOogfGks5u4PqjgaJpZM4TdU9q .
AFAIK under Linux pam_unix uses a suid helper /usr/bin/unix_chkpwd to check the password against /etc/shadow (which is user unreadable). So pam_yubico should either implement something similar, or use files in $HOME.
OTOH, pam_google_authenticator uses $HOME/.google_authenticator, so that should just work, but swaylock needs to support the full pam conversation.
Just to mention that the pam-u2f module seems to work fine with swaylock, which is another option for mfa with yubikey.
Just to mention that the pam-u2f module seems to work fine with swaylock, which is another option for mfa with yubikey.
@hughwilliams94 How are you using this to interact with swaylock? I have a Librem Key on the way and my understanding is it supports pam-u2f.
I have two Yubikeys (4 and 5). I have installed pam-u2f from the Arch Linux community repo (this package is developed by Yubico so may not be compatible with the Librem Key). I then have my /etc/pamd.d/login file setup thus:
#%PAM-1.0
auth required pam_securetty.so
auth requisite pam_nologin.so
auth required pam_u2f.so authfile=/etc/u2f_mappings cue
auth include system-local-login
auth optional pam_gnome_keyring.so
account include system-local-login
session include system-local-login
session optional pam_gnome_keyring.so auto_start
(Note the gnome_keyring details are unrelated to U2F so may not be relevant to your use-case.)
and my /etc/pam.d/swaylock setup thus:
#
# PAM configuration file for the swaylock screen locker. By default, it includes
# the 'system-auth' configuration file (see /etc/pam.d/login)
#
auth include system-auth
auth required pam_u2f.so authfile=/etc/u2f_mappings cue
I am not sure why the change to /etc/pam.d/swaylock is necessary; however, if I don't insert the second auth line, swaylock does not reliably require the Yubikey.
The /etc/u2f_mappings file needs to include the out put of the following command (this utility is developed by yubikey so may not work with Librem):
pamu2fcfg -uusername -opam://myorigin -ipam://myappid.
Most of the details are explained pretty clearly here (although these details are Yubikey specific so the Librem Key may have a different setup utility).
How else are you gonna authenticate against the system password on FreeBSD? There you must be root to do that, even with PAM.
Yup it does not work under FreeBSD... so you cannot unlock on FreeBSD even with correct pam settings and correct password. You can verify with pamtester that pam_unix.so only is working when pamtester is running as root
I followed this guide Universal 2nd Factor Have the same pam config as for sudo
auth sufficient pam_u2f.so origin=pam://<hostname> appid=pam://<hostname>
and it works. Need to write something and press Enter before push SoloKey's button though.
Can confirm that swaylock works with solokey!
/etc/pam.d/swaylock looks like this:
auth sufficient pam_u2f.so authfile=/etc/u2f_mappings cue
auth include login
I've also added the following line to /etc/pam.d/login, under account required pam_nologin.so:
auth sufficient pam_u2f.so authfile=/etc/u2f_mappings cue
Need to write something and press Enter before push SoloKey's button though.
FWIW, on Fedora 33, as of 2021-04-11 I don't have to type anything; I just press the button on my solokey and then RET.
Need to write something and press Enter before push SoloKey's button though.
I have a fingerprint reader using pam_fprint and also noticed the weird "need to first enter a dummy password and hit enter, and only then the fingerprint reader will let me in" behavior with swaylock.
account required pam_unix.so
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so likeauth try_first_pass
auth required pam_deny.so
password sufficient pam_unix.so nullok sha512
session required pam_env.so conffile=/etc/pam/environment readenv=0
session required pam_unix.so
EDIT: https://github.com/swaywm/swaylock/issues/61 is about that oddity.
This can probably be closed as not planed if the developers don't want to add extra code to support something like specific input fields. A yubikey for example works as auth method as long as you don't need to enter a pin and use the u2f pam module.
