Remove support for shadow(5)'s sp_min#1482
Conversation
|
The use case for the minimum password age is to prevent lazy people in environments where periodic password changes are required, knowing that they can't reuse 10 last passwords, from changing the password 10 times to throwaway values and then back to the original. In practice, even though it is not explicitly regulated, auditors view it as a part of enforcement of the password history requirement. |
That's actually not lazy people, but intelligent people that know ways of enforcing security even under regulations that actively try them to decrease security.
Auditors can come here and talk with us. :) |
alejandro-colomar
force-pushed
the
sp_min
branch
from
c8f041d to
6163906
Compare
alejandro-colomar
force-pushed
the
sp_min
branch
from
6163906 to
8bbd970
Compare
alejandro-colomar
force-pushed
the
sp_min
branch
2 times, most recently
from
07061db to
f1d901d
Compare
alejandro-colomar
force-pushed
the
sp_min
branch
2 times, most recently
from
719cd63 to
678e391
Compare
|
So I like this for simplifying the code, and for not encouraging dumb policies. But I don't like enforcing my own opinions on other people or organizations. If there were a request to enable it and we didn't yet support it, I'd be happy to say no. But removing existing support and breaking people's current scripts is a different thing. (Not nacking outright, let's talk...) |
I think this shouldn't break anyone's scripts:
Those scripts will not produce the intended effects, which are to prevent users from changing their passwords, but I wouldn't say that's fundamentally breaking the scripts. Another point of view is that this whole feature is a security bug:
I think this case would warrant removing the feature, even if it may ignore the effects of some existing scripts. Does this sound reasonable?
|
|
@ikerexxe , would you mind having a look at the failing tests? They were added recently, and I'm not sure why they're failing. Edit: In v3, I removed those tests, which worked, but in v4, I tried to keep them (and adapt them), which seems to fail for unprivileged tests. |
Self correction: I was thinking of scripts that handle /etc/shadow directly. This change would indeed break scripts that call these tools with the flags we'd be removing. We could accept the flags and ignore them, but I think that'd be worse. I think this breakage would be acceptable, considering the security problem of minimum periods of changing passwords. In fact, I think this deserves a CVE. @ikerexxe , would you mind contacting Red Hat for issuing a CVE against shadow for the sp_min field? Here's a draft they can use: Edit: I've sent an email to Debian security@, in case they can issue the CVE. |
alejandro-colomar
force-pushed
the
sp_min
branch
2 times, most recently
from
0da7692 to
c94dd09
Compare
|
Thanks!! :) |
Link: <shadow-maint#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Link: <shadow-maint#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
It makes no sense to limit the frequency of password change. If one changes its password, and 5 minutes later the password is leaked, one should be able to change the password immediately. Link: <shadow-maint#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Link: <shadow-maint#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Whenever we were reading it, let's assume it contains a -1 (the integer representation of an empty field). Whenever we were writing it, let's write a -1. I think this would be worth a CVE. I've contacted Debian, in case they can issue a CVE. Here's the draft I've sent them for the CVE: shadow-utils: inability to change a compromised password Description A flaw was found in /etc/shadow, and the programs that handle the file. The /etc/shadow database (documented in shadow(5)) entries contain a "minimum password age" field. This field imposes a minimum password age before the password can be changed. If a user's password is compromised before that period expires, the user must contact the administrator to be able to change the password. This can usually take hours or days, and during these hours or days, an attacker would have unlimited access to the credentials. One option of the user would be to lock its own password with 'passwd -l', thus being locked out of its own account. The history of this 4th field of /etc/shadow entries is considered dubious in retrospective, and the recommended action is to never set this field. If the field is set, the recommended action is to ignore the field, and if possible, remove it. Link: <shadow-maint#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Link: <shadow-maint#1482> Signed-off-by: Alejandro Colomar <alx@kernel.org>
alejandro-colomar
force-pushed
the
sp_min
branch
from
c94dd09 to
d6462d5
Compare
alejandro-colomar
merged commit 34f78dc
into
shadow-maint:master
Link: <#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Link: <#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
It makes no sense to limit the frequency of password change. If one changes its password, and 5 minutes later the password is leaked, one should be able to change the password immediately. Link: <#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Link: <#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Whenever we were reading it, let's assume it contains a -1 (the integer representation of an empty field). Whenever we were writing it, let's write a -1. I think this would be worth a CVE. I've contacted Debian, in case they can issue a CVE. Here's the draft I've sent them for the CVE: shadow-utils: inability to change a compromised password Description A flaw was found in /etc/shadow, and the programs that handle the file. The /etc/shadow database (documented in shadow(5)) entries contain a "minimum password age" field. This field imposes a minimum password age before the password can be changed. If a user's password is compromised before that period expires, the user must contact the administrator to be able to change the password. This can usually take hours or days, and during these hours or days, an attacker would have unlimited access to the credentials. One option of the user would be to lock its own password with 'passwd -l', thus being locked out of its own account. The history of this 4th field of /etc/shadow entries is considered dubious in retrospective, and the recommended action is to never set this field. If the field is set, the recommended action is to ignore the field, and if possible, remove it. Link: <#1482> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
The latest version looks good. If we are to ignore the attribute, then let's stop checking it.
Since you’ve already got in touch with the Debian security team, let’s continue along those lines. At this stage, I assume that all the teams dealing with CVEs are swamped at the moment, and I don’t want to add to their workload any more than they already have |
4 participants
Password expiry was deprecated in 4.19.
sp_min(password minimum age) doesn't seem to be regulated, so it seems we can remove it already.Link: #1432
Revisions:
v1b
v2
v2b
v2c
v2d
v3
v4
v4b
v4c
v5
v5b