FS#67393 - [shadow][pambase] Stop overriding the specified ENCRYPT_METHOD in /etc/login.defs

Attached to Project: Arch Linux
Opened by loqs (loqs) - Saturday, 25 July 2020, 17:25 GMT
Last edited by David Runge (dvzrv) - Friday, 22 September 2023, 20:34 GMT
Task Type Feature Request
Category Packages: Testing
Status Closed
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
The method is currently overridden in all its uses meaning the actual value specified in /etc/login.defs has no effect.
This could cause confusion. Also synchronizing a setting in multiple locations can introduce errors.
It is used in at least:
* /etc/pam.d/chpasswd
* /etc/pam.d/newusers
* /etc/pam.d/passwd
* /etc/pam.d/system-auth

PKGBUILD.diff.shadow removed all uses of sha512. Changed dropped module pam_cracklib.so to pam_pwquality.so, man page lists parameters as being the same but I have not checked this.
PKGBUILD.diff.pambase removed use of sha512.

Additional info:
* shadow 4.8.1-3
* pambase 20190105.1-2
This task depends upon

Closed by  David Runge (dvzrv)
Friday, 22 September 2023, 20:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with pambase 20230918, shadow 4.14.0-3
Comment by Tobias Powalowski (tpowa) - Wednesday, 12 August 2020, 19:40 GMT
pambase-20200721.1-2 should fix this, shadow is pending.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 14 September 2020, 19:14 GMT
Will make the suggested changes to shadow later this week
Comment by Geert Hendrickx (ghen) - Thursday, 10 December 2020, 10:04 GMT
The direct pam config allows more choices than ENCRYPT_METHOD in /etc/login.defs though, which can only be set to DES, MD5, SHA256, SHA512 or (undocumented) BCRYPT.
pam_unix(8) supports more algorithms, like yescrypt.
Comment by Geert Hendrickx (ghen) - Thursday, 10 December 2020, 19:17 GMT
Btw, upstream is planning to handle this differently in the future, and rely on libxcrypt's crypt_preferred_method() instead of a (potentially dated) system preference:
https://github.com/linux-pam/linux-pam/pull/84
Comment by loqs (loqs) - Saturday, 05 June 2021, 22:19 GMT
The pambase-20200721.1-2 change was reverted by pambase 20210605-1: hash with sha512 by default.

Should this be closed as Won't Fix?
Comment by Geert Hendrickx (ghen) - Sunday, 06 June 2021, 19:47 GMT
The crypt(5) manpage lists sha512crypt as "acceptable" (if properly configured, not by default), but recommends yescrypt for new hashes.
Comment by loqs (loqs) - Sunday, 06 June 2021, 21:00 GMT
@ghen you want to submit a patch changing all use of sha512 in pam files to yescrypt, adding it to pam_unix password entries that do not specify an encryption method and removing it from /etc/login.defs?
You could also standardize the use of nullok. You could also consider changing physlock and kbd to using upstreams pam configs that use system-auth rather directly using pam_unix.
Edit:
man 5 crypt notes 5000 rounds is too low for modern hardware for sha512/sha256 but does not provide a recommended number of rounds.
Does the libxcrypt project have a recommendation for the number of rounds that currently could be used? That could then be set in upstream shadows login.defs.
Or patch shadow with yescrypt support [1] and add the option there?

[1] https://github.com/shadow-maint/shadow/commit/5cd04d03f94622c12220d4a6352824af081b8531
Comment by David Runge (dvzrv) - Sunday, 16 October 2022, 16:23 GMT
I've added the options to build with bcrypt and yescrypt support in SVN (https://github.com/archlinux/svntogit-packages/commit/7d5415618a1e99bb57b873e17224cb8f254d7280).
Comment by David Runge (dvzrv) - Thursday, 20 October 2022, 08:43 GMT
FWIW, it appears that Fedora builds shadow without libpam support (https://src.fedoraproject.org/rpms/shadow-utils/blob/rawhide/f/shadow-utils.spec#_155)
I wonder why that is and how they configure PAM instead.
Comment by lukpod (lukpod) - Friday, 28 October 2022, 12:47 GMT Comment by loqs (loqs) - Monday, 31 October 2022, 23:20 GMT
With pam, pam_unix.so uses ENCRYPT_METHOD from longin.defs [1] overridden by des md5 bigcrypt sha256 sha512 blowfish gost_yescrypt yescrypt [2] and SHA_CRYPT_MAX_ROUNDS [3] overridden by rounds=n. The rest of the pam stack is used.

Without pam ENCRYPT_METHOD supported values des md5 sha256 sha512 bcrypt yescrypt, SHA_CRYPT_MIN_ROUNDS SHA_CRYPT_MAX_ROUNDS BCRYPT_MIN_ROUNDS BCRYPT_MAX_ROUNDS YESCRYPT_COST_FACTOR [4] may be used.

des md5 sha256 sha512 bcrypt yescrypt intersection with des md5 bigcrypt sha256 sha512 blowfish gost_yescrypt yescrypt is des md5 sha256 sha512 yescrypt eliminating des and md5 leaves sha256 sha612 yescrypt.
scrypt bcrypt sha1crypt SunMD5 bsdicrypt NT are supported by libxcrypt [5] but not by pam_unix [2].

[6] Changes the ENCRYPT_METHOD documentation in login.defs to list the methods supported by pam_unix and removes the per method rounds settings.
[7] and [8] Adds a ROUNDS option to login.defs and changes pam_unix's undocumented support for SHA_CRYPT_MAX_ROUNDS to support it mirroring the rounds option pam_unix already supports.

#SHA_CRYPT_MAX_ROUNDS 5000
pam_unix min 1000 max 9999999 default 5000

#YESCRYPT_COST_FACTOR 5
pam_unix min 3 max 11 default 5

How does Fedora avoid a different number of rounds and or encryption method being used between tools that use pam such login when a password change is forced due to it being expired compared to passwd which Fedora builds without pam?

[1] https://github.com/linux-pam/linux-pam/blob/v1.5.2/modules/pam_unix/support.c#L85
[2] https://github.com/linux-pam/linux-pam/blob/v1.5.2/modules/pam_unix/support.h#L109
[3] https://github.com/linux-pam/linux-pam/blob/v1.5.2/modules/pam_unix/support.c#L103
[4] https://man.archlinux.org/man/login.defs.5
[5] https://man.archlinux.org/man/crypt.5
[6] shadow-encrypt-methods-supported-by-pam-unix.patch
[7] shadow-rounds.patch
[8] pam-rounds.patch
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by loqs (loqs) - Wednesday, 09 August 2023, 14:45 GMT
Still an issue.
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 10:49 GMT
The change to pambase has been applied in https://gitlab.archlinux.org/archlinux/packaging/packages/pambase/-/commit/b31c2ce4facf27032c46439e3ce4fa5576d8571f

@loqs: What is your opinion on https://bugs.archlinux.org/task/69715#comment222158 (as this is closely related to the PAM files for shadow).
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 11:39 GMT
@loqs: Hm, I just realized your proposed solution heavily relies on patching pam and shadow to make this work. I'm not sure I'm entirely comfortable with this solution.
Comment by loqs (loqs) - Monday, 18 September 2023, 12:05 GMT
> @loqs: Hm, I just realized your proposed solution heavily relies on patching pam and shadow to make this work. I'm not sure I'm entirely comfortable with this solution.
Do you want to contact upstream on the issue of supporting different cost factors? This issue could be marked implemented as SHA512 is no longer forced.
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 12:41 GMT
> Do you want to contact upstream on the issue of supporting different cost factors? This issue could be marked implemented as SHA512 is no longer forced.

Judging from the source code, the cost factor is supported via "rounds": https://github.com/linux-pam/linux-pam/blob/77bd338125cde583ecdfb9fd69619bcd2baf15c2/modules/pam_unix/support.c#L188-L195
However, I guess it would be good to also support reading of `YESCRYPT_COST_FACTOR` from /etc/login.defs for that purpose!
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 12:47 GMT
I have opened an upstream ticket with linux-pam to have this tracked: https://github.com/linux-pam/linux-pam/issues/607
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 13:46 GMT
There is now filesystem 2023.09.18-1, pambase 20230918-1 and shadow 4.14.0-1 in [core-testing].

Please give it a thorough test and report back with any problems!

Loading...