Skip to main content

max / alloy

1.7 KB · 41 lines History Blame Raw
1 # Alloy brute-force policy.
2 #
3 # Replaces the stock pam faillock.conf, which ships every option commented
4 # out and therefore states nothing. The numbers here are secureblue's, and
5 # they are deliberately loose: this is a defence against an attacker
6 # guessing, not against a person mistyping.
7 #
8 # The PAM stack that reads this is turned on by
9 # `authselect enable-feature with-faillock` in the Containerfile. Without
10 # that, this file is inert — which is the exact failure this project's
11 # polkit and fingerprint blocks are asserted against, so it is asserted too.
12 #
13 # WHAT IT COSTS: fifty consecutive failures locks the account for a day. A
14 # person who has genuinely done that has a bigger problem than the lockout,
15 # and the escape hatch is `faillock --user <name> --reset` as root, from
16 # another session or a VT.
17 #
18 # WHAT IT DOES NOT COVER: ssh, because sshd on Alloy takes keys only
19 # (etc/ssh/sshd_config.d/10-alloy.conf). There is no password to guess over
20 # the network. This is about the console, the greeter and the lock screen.
21
22 # Fifty attempts before the door closes.
23 deny = 50
24
25 # Twenty-four hours, then it opens on its own. `unlock_time = 0` would mean
26 # root-only recovery, which on a single-user laptop is how you brick your own
27 # machine.
28 unlock_time = 86400
29
30 # Failures on the root account count too. Off by default; a root console
31 # login is exactly the thing worth rate-limiting.
32 even_deny_root
33 root_unlock_time = 900
34
35 # Count failures in a rolling fifteen-minute window rather than forever.
36 fail_interval = 900
37
38 # Say how many attempts are left. Telling an attacker is worth less than a
39 # person understanding why their next attempt is about to lock them out.
40 audit
41