1 |
On Wednesday, 14 October 2020 21:18:38 GMT Michael Jones wrote: |
2 |
> With the recent update to sys-auth/pambase-20201013, i find myself |
3 |
> struggling to understand how to adapt the new default configuration to work |
4 |
> with winbind. |
5 |
> |
6 |
> I'm writing to the list for help with this. |
7 |
> |
8 |
> First, I'll provide my current system-auth, the new system-auth that comes |
9 |
> from sys-auth/pambase-20201013, and my attempt at merging the two versions. |
10 |
> After those items, I have several questions which I'll ask at the end of my |
11 |
> email. |
12 |
> |
13 |
> |
14 |
> |
15 |
> First, here's my current /etc/pam.d/system-auth file: |
16 |
> |
17 |
> auth required pam_env.so |
18 |
> auth sufficient pam_unix.so try_first_pass likeauth nullok |
19 |
> auth sufficient pam_winbind.so use_first_pass |
20 |
> auth required pam_deny.so |
21 |
> |
22 |
> account sufficient pam_unix.so |
23 |
> account required pam_winbind.so |
24 |
> |
25 |
> password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 |
26 |
> retry=3 |
27 |
> password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 |
28 |
> shadow |
29 |
> password sufficient pam_winbind.so use_authtok |
30 |
> password optional pam_permit.so |
31 |
> |
32 |
> session required pam_limits.so |
33 |
> session required pam_env.so |
34 |
> session required pam_unix.so |
35 |
> session required pam_winbind.so |
36 |
> session optional pam_permit.so |
37 |
> |
38 |
> |
39 |
> Here's the new version that comes from sys-auth/pambase-20201013 with the |
40 |
> useflags: gnome-keyring nullok passwdqc sha512 systemd |
41 |
> |
42 |
> auth required pam_env.so |
43 |
> auth required pam_unix.so try_first_pass likeauth nullok |
44 |
> auth optional pam_permit.so |
45 |
> auth required pam_faillock.so preauth |
46 |
> auth sufficient pam_unix.so nullok try_first_pass |
47 |
> auth [default=die] pam_faillock.so authfail |
48 |
> account required pam_unix.so |
49 |
> account optional pam_permit.so |
50 |
> account required pam_faillock.so |
51 |
> password required pam_passwdqc.so config=/etc/security/passwdqc.conf |
52 |
> password required pam_unix.so try_first_pass use_authtok nullok sha512 |
53 |
> shadow |
54 |
> password optional pam_permit.so |
55 |
> session required pam_limits.so |
56 |
> session required pam_env.so |
57 |
> session required pam_unix.so |
58 |
> session optional pam_permit.so |
59 |
> |
60 |
> |
61 |
> Here's my attempt at merging these two together. |
62 |
> |
63 |
> auth required pam_env.so |
64 |
> auth required pam_faillock.so preauth |
65 |
> auth sufficient pam_unix.so nullok try_first_pass |
66 |
> auth sufficient pam_winbind.so use_first_pass |
67 |
> auth requisite pam_faillock.so authfail |
68 |
> |
69 |
> account required pam_faillock.so |
70 |
> account sufficient pam_unix.so |
71 |
> account sufficient pam_winbind.so |
72 |
> account optional pam_permit.so |
73 |
> |
74 |
> password required pam_passwdqc.so |
75 |
> config=/etc/security/passwdqc.conf |
76 |
> password sufficient pam_unix.so try_first_pass use_authtok nullok |
77 |
> sha512 shadow |
78 |
> password sufficient pam_winbind.so use_authtok |
79 |
> password optional pam_permit.so |
80 |
> |
81 |
> session required pam_limits.so |
82 |
> session required pam_env.so |
83 |
> session required pam_unix.so |
84 |
> session required pam_winbind.so |
85 |
> session optional pam_permit.so |
86 |
|
87 |
I'd rather not comment on the above in case my understanding is incorrect and |
88 |
you end up breaking access to your system. ;-) |
89 |
|
90 |
Some answers/thoughts below. |
91 |
|
92 |
|
93 |
> Questions: |
94 |
> |
95 |
> 1. Why does sys-auth/pambase use the "likeauth" flag? I cannot find any |
96 |
> real information about this except for a redhat bugzilla ticket that says |
97 |
> it's for legacy usage from 2004. |
98 |
> https://bugzilla.redhat.com/show_bug.cgi?id=120418 |
99 |
|
100 |
I don't know if this is still required, or is now deprecated. This thread |
101 |
referenced in the bug you mention provides some explanation: |
102 |
|
103 |
https://www.spinics.net/lists/pam/msg03533.html |
104 |
|
105 |
I understand it to mean when an application asks pam_unix.so to set a new |
106 |
passwd this will use the same authentication criteria/limits checks, as an |
107 |
existing authentication credentials would be normally checked against. |
108 |
|
109 |
|
110 |
> 2. Why is pam_faillock.so used with "preauth" after the first use of |
111 |
> pam_unix.so ? The manpage for pam_faillock.so says that faillock should be |
112 |
> called with the "preauth" command prior to asking for the user's password. |
113 |
|
114 |
I think if the pam_unix.so in the preceding line has been used by an |
115 |
application to set a new passwd, the passwd will be asked/checked at the |
116 |
subsequent pam_unix.so line, which is below the pam_faillock.so. I admit this |
117 |
logic is not particularly sound, if the preceding pam_unix.so line is not |
118 |
setting a new passwd, just asking/checking what is submitted. :-/ |
119 |
|
120 |
|
121 |
> 3. Why is pam_permit.so used as the last item in each section other than |
122 |
> auth? The manpage for pam_permit indicates that this module always returns |
123 |
> success. Using it as an optional module is a no-op. |
124 |
|
125 |
The pam_permit module is meant to set an application user as 'nobody', some |
126 |
applications run with this user name and no passwd. |
127 |
|
128 |
The optional control flag means it will continue checking the rest of the |
129 |
stack. |
130 |
|
131 |
|
132 |
> 4. Why is pam_faillock.so the last module for the "account" type, instead |
133 |
> of the first module, as from the example in the manpage? |
134 |
|
135 |
The preceding control flag is set to be 'sufficient' for pam_unix.so. If the |
136 |
pam_unix.so succeeds and no previous 'required' modules have failed, any |
137 |
modules following it will not be checked. Authentication would have been |
138 |
successful. If however, failures have already taken place in previous checks |
139 |
in the stack or in the current pam_unix.so check, subsequently the |
140 |
pam_faillock.so will be checked against. |
141 |
|
142 |
|
143 |
> 5. Why use [default=die] instead of requisite for pam_faillock.so in the |
144 |
> auth section? |
145 |
|
146 |
I think 'requisite' will inform the application of repeated failed |
147 |
authentications and consequently inform an attacker of potentially valid user |
148 |
accounts. The [default=die] will cause pam_faillock.so to register an |
149 |
authentication failure and in addition terminate pam and cancel any futher |
150 |
checks down the module stack. |
151 |
|
152 |
My understanding of PAM is ropey to put it mildly, so someone more versed in |
153 |
its logic should hopefully chime in to correct any mistakes. |