You are not logged in.

#1 2021-01-02 02:37:14

simon
Member
Registered: 2005-12-06
Posts: 9

[SOLVED] PAM delay

The PAM documentation on the wiki appears to be incomplete or out-of-date when it comes to modifying the (failed) login delay time...however, I want to check that I haven't just missed something obvious before suggesting an update. PAM is largely mysterious to me so it's possible others with a better understanding of it can extrapolate the necessary settings from the man pages etc.: I have read them, but so far haven't been able to translate them into a working configuration.

My aim is simply to reduce the failed login delay from the frustrating and unnecessary (to me...I have no problem with it as a default) three second delay to something more reasonable (0.5s or at most 1s...enough to make brute force attacks absurd without also forcing people to sit around waiting every time they make a typo)...however as a first step towards this, and purely to test that the system is actually responding to my configuration changes, I'm attempting to eliminate it completely (i.e. set it to zero).

The process for adjusting this value has been messy for years due to the system's having not one but two seemingly ignored configuration options (the pam_faildelay.so setting documented in the Arch wiki, and the self-explanatory /etc/login.defs "FAIL_DELAY" setting), both of which can appear at first to be completely ignored because there is an additional hard-coded delay that needs to be disabled with a "nodelay" option for pam_unix.so. I have all this working on my Debian boxes but am setting up a new Arch install and the PAM settings that worked on Debian don't work with Arch. Rather than continuing to poke around at random, adding nodelay options to every line with pam_unix.so in it (to no avail so far), I'd be grateful for a concise (even one-line) howto for Arch (along the lines of "add 'nodelay' to line foo in file foo, add your desired pam_faildelay.so setting to line foo in file foo, and forget about login.defs" or whatever)...or a link to where this information exists in the Arch documentation, as I've been unable to find it. I've searched the forums too, and none of the answers I found provide a solution that actually works. The annoyingly long (several seconds) delay won't budge.

Last edited by simon (2021-01-03 02:24:23)

Offline

#2 2021-01-02 07:45:14

seth
Member
Registered: 2012-09-03
Posts: 20,444

Re: [SOLVED] PAM delay

We're talking about the agetty login?
login.defs doesn't apply because arch uses the agetty binary from util-linux instead of the shadow agetty, https://bbs.archlinux.org/viewtopic.php … 8#p1942418

Since the undesired delay is (most likely) coming from the getty, fumbling in PAM won't help, but you could replace the agetty w/ the shadow version.
Please report back in case (and mark the thread as solved) because two hits in a month make me feel like maybe there needs to be a discussion as to whether we use the "right" agetty ;-)

Offline

#3 2021-01-02 09:21:55

simon
Member
Registered: 2005-12-06
Posts: 9

Re: [SOLVED] PAM delay

Thanks, Seth, for this reply. I don't really understand what you're asking me to do and then report back about. Edits to PAM configs (specifically setting the pam_faildelay value, as described in the Arch wiki, plus appending "nodelay" to the pam_unix.so line in the relevant /etc/pam.d file) have successfully modified this delay on other distros (I've seen nice quick delays on Debian, Ubuntu, CentOS, Slackware and Gentoo boxes...in fact I don't think I've ever encountered a distro in which this hasn't been possible before)...but are you saying that this simply isn't possible with the agetty that Arch uses, and so advising me to replace the default agetty with something else to see if this causes the PAM configuration to work properly? If so, can I be confident that the "right" agetty (once installed) will in all other respects function exactly like the Arch default? I don't want to swap out components of the base system just for the sake of a minor inconvenience if doing so could cause new problems.

Offline

#4 2021-01-02 09:39:44

seth
Member
Registered: 2012-09-03
Posts: 20,444

Re: [SOLVED] PAM delay

1st ensure tat this is about the getty login (linux console) and not some DM (GDM, SDDM, lightdm, ...)

The shadow version of rather the "login" binary (sorry, pre-caffeine error) is in widespread use, but will not behave exactly the same (eg. the sigint situation in the other thread) in every other regard.

You may expect it to allow you to login, but when messing w/ this kind of stuff you want ensure to have offline access to the system (ie. a live-distro that allows you to undo changes to the filesystem w/o having to log into the installed system, ie. keep the present login as "login.util-linux" and iff the shadow login fails, restore rhat file

Offline

#5 2021-01-02 15:22:01

seth
Member
Registered: 2012-09-03
Posts: 20,444

Re: [SOLVED] PAM delay

Update: I looked at the code of util-linux/login and the FAIL_DELAY of login.defs is actually parsed and I can use it to impact the delay *after* pam fails the authentication.
(so no need to test the shadow version itr)

I can however confirm an ~3s delay before the authentication fails and that's not impacted by passing "nodelay" to pam_unix in system-auth.

Edit: castrating system-auth to "… required pam_unix … nodelay" causes an instant failure so it's one of the other modules (probably pam_faillock, but didn't test yet)

Edit #2: Yup, is faillock.
config doesn't seem to allow controlling the delay.

Edit #3, lookee: https://github.com/linux-pam/linux-pam/issues/295

Last edited by seth (2021-01-02 15:58:32)

Offline

#6 2021-01-02 20:08:50

simon
Member
Registered: 2005-12-06
Posts: 9

Re: [SOLVED] PAM delay

Nice detective work there. It seems bizarre to me that the folk coding these (PAM) modules are building their own separate hard-coded delays into so many different modules (so that we now have FOUR places we have to examine to squash the delay: the system administrator's login.defs file...and then no less than three different PAM modules, pam_faildelay.so, pam_unix.so...and now pam_faillock.so as well)...but from the linux-pam issue you found, it looks as though that really is the case. Three different PAM modules, each adding its own delay to the pile. Those PAM folk really, really like to slow things down!

I won't mark the thread as solved until I'm actually seeing the shorter delay, but thank you, it looks like you've solved the mystery. It looks as though pam_faillock is just a nuisance module (for my setup) anyway: if my password's secure (and as long as I have a small delay between attempts) it's not going to be brute forced, so I don't really want to enable attackers to lock up the account simply by failing enough of their futile login attempts. This being the case (and given that faillock isn't here on my Debian systems) I'm just going to try commenting out all the faillock lines (when I get a chance, probably in a couple of hours). If I can't suppress it that way, the discussion you found pinpoints the exact line of code I need to edit so one way or another, this delay's getting squashed. I'll report back when it is. Thanks again.

Offline

#7 2021-01-02 21:12:02

simon
Member
Registered: 2005-12-06
Posts: 9

Re: [SOLVED] PAM delay

OK...delay squashed, so mission accomplished in that respect...however...with my ignorance of how PAM works, I don't think it's safe to assume that this problem has been properly solved simply because everything *appears* to be working as it should, when I test (local shell, immediately after booting) logins. Yes, correct login details log me in immediately (great) and incorrect details lock me out with exactly the delay I've specified in the pam_faildelay.so line (great)...however, I've basically achieved this by replacing a much longer and more complex-looking Arch default system-auth...

auth       required                    pam_faillock.so      preauth
auth       [success=2 default=ignore]  pam_unix.so          try_first_pass nullok
-auth      [success=1 default=ignore]  pam_systemd_home.so
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
-account   [success=1 default=ignore]  pam_systemd_home.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so
-password  [success=1 default=ignore]  pam_systemd_home.so
password   required                    pam_unix.so          try_first_pass nullok shadow
password   optional                    pam_permit.so
session    required                    pam_limits.so
session    required                    pam_unix.so
session    optional                    pam_permit.so

...with a very simple one based on my Debian configuration...

auth optional pam_faildelay.so delay=1000000
auth    [success=1 default=ignore]    pam_unix.so nullok_secure nodelay
auth    requisite            pam_deny.so
auth    required            pam_permit.so

...and whereas I can see that the lines in the default Arch config referencing pam_env.so, pam_time.so and pam_limits.so are useless to me (they either load fully commented-out configs like /etc/security/limits.conf, or simply enable functionality I don't need), the systemd_home module looks potentially useful and in any case I'm reluctant to assume that what might be secure on a Debian setup (in which the rest of /etc/pam.d is configured differently) is still secure on Arch.

The less drastic change I'd hoped to make (simply commenting the faillock lines out of system-auth) didn't work: for some reason (as I said, PAM is basically a mystery to me) this enabled successful logins regardless of details entered! So at this point I'm going to start with the above seemingly working config, and will try adding back the Arch defaults (or at least the systemd_home lines), in the hopes that the final result will be a configuration that not only seems to work (as it already does), but actually does work (as a trustworthy PAM configuration, without some kind of gaping security hole I've unwittingly opened up here). I'd be grateful for advice from you or anyone else who actually understands PAM. Otherwise, I guess if I don't receive any advice that this solution is flawed, I'll post my final system-auth setup as a reference for anyone else wanting to squash the login delay (to one second, with the delay=1000000 setting), and mark the thread as solved.

Offline

#8 2021-01-02 21:54:13

seth
Member
Registered: 2012-09-03
Posts: 20,444

Re: [SOLVED] PAM delay

login.defs isn't part of PAM.
faillock's job is to restrict your faulty attempts to login (so after 3 failures you've to wait like 15 minutes to try again) - it just replaced pam_tally
I don't really understand why pam_unix (possibly for historic reasons) and pam_faillock (possibly "felt" related) perform pam_faildelay's job

Just commenting the faillock pam will lead to pam_permit accidentally being skipped but also is "ignore"d in every case but success (including in failure) and there's nothing left to intercept the bad password (unlike the debian variant where everything *but* success runs into pam_deny which unconditioanally tells you to gtfo)

I'd keep the pam_unix/permit lines for account, password and session (idk from the top of my head but would certainly check whether yo can otherwise eg. alter your password w/o having to provide the proper old one)

Offline

#9 2021-01-03 00:45:39

simon
Member
Registered: 2005-12-06
Posts: 9

Re: [SOLVED] PAM delay

Yes, I understand that login.defs is not part of PAM...but the two packages handle actual logins together so could still be configured to play together nicely. I'm not claiming the PAM developers have done anything wrong...I guess there could be plenty of use cases where login's not involved and yet an enforced delay is necessary...but still, having a default PAM configuration (not just on Arch, but I think every Linux distro I've used enough to become annoyed by the long login fail delay) that can see an administrator's one-second "FAIL_DELAY" setting right there in login.defs and then delays failed logins by six seconds regardless (1s FAIL_DELAY +2s pam_unix +3s failllock) is a clumsy, less-than-ideal configuration. I don't know enough about PAM to suggest an ideal approach...my completely uninformed suggestion would be that it parses login.defs and applies that (total) delay to actual logins and then in other scenarios where it's not being used to authenticate a login, it reverts to its hard-coded defaults...but I do know that I prefer it when stuff like this can be configured with one simple setting (after which the code does the work of figuring out how best to take that setting into account, in different situations) rather than having to waste time tweaking separate things all over the place.

After mucking around tweaking things all over the place (and thanks to your help, identifying faillock as the new problem), logins do appear to be working exactly how I like them now, so I'm going to mark the thread solved. I'll keep the default system-auth there for reference just in case I hit a problem later on, but at this point the abbreviated version seems to be handling things correctly. I won't post my configs for future reference in case they're dodgy, but the basic steps that work in other distros (FAIL_DELAY to 0, nodelay after pam_unix calls and pam_faildelay set to the actual desired delay) appear to work in Arch too, once faillock's removed (and after adding an explicit pam_faildelay line to the end of the su config as well, in pam.d). Thanks again, Seth, for tracking the issue down: problem solved.

Offline

Board footer

Powered by FluxBB