Unrelated to the auth bypass, but on the topic of linux-pam; this summer I landed exposing prctl(PR_SET_NO_NEW_PRIVS) in pam_limits [0]. It's a convenient way to prevent logins from potentially attaining new privileges, even if bad actors find bugs in suid programs or even know the root password (assuming remote root logins are disabled).
I would love to see no_new_privs more widely used, so thanks!
Unfortunately it should be noted on most distributions this will cause counterintuitive breakages -- most notably ping won't work for unprivileged users (but luckily you can fix this by changing net.ipv4.ping_group_range to include the unprivileged user groups -- I hope distributions fix this eventually...).
Does that actually fix it? The linked email listing says the issue is that logging in as a non-existent user with an empty password will work, and the fix that you linked seems to just make it harder to figure out if a user doesn't exist. That doesn't seem like it fixes anything; there's no need to determine beforehand if a user doesn't exist to use this exploit, since you could just try to use the exploit with an arbitrary username, and if it works, then obviously the user doesn't exist.
I hate to be that guy, but _damn_ does PAM seem ripe for being rewritten in Rust. Maybe it's the PTSD speaking, but seeing vanilla C string operations in a security-critical library makes my hair stand on end.
Searching around, the best I can find is one 0.1 crate that hasn't seen activity since 2017:
Please, instead, let's have something that isn't a shared library loaded into everything. Something usable by contained/isolated/sandboxed software just by giving them a unix domain socket to talk to, with no need to share /etc/shadow.
You should definitely write an MVP and come back with one. Or write a blog post explaining what parts would benefit and why it is a clear cut case for a rewrite and then post it here.
PAM is an authn core in any modern mainstream Linux distro. If you build and/or tweak Linux boxes, PAM was almost always here right with you. The only question is do you know what exacly PAM do?
I remember when I was in school (about 15 years ago) Slackware was one of the few distro's that didn't have PAM and they made a big point of it. So I did a quick Google just now and found that this year (2020) even Slackware got PAM [1]. Had a good chuckle over that.
It's saying something that rolling-your-own is even a debatable alternative to PAM (because if there's a flaw in your program, "only" that program is vulnerable, not the whole system. "Only" in quotes because it's just one privilege escalation step away)
What is "built-in auth" for a console login or SSH?
Before you come up with an answer involving /etc/shadow and crypt(), consider that not all systems use local password files... and that you've just reinvented what PAM does, except less flexible and more prone to implementation errors.
[0] https://github.com/linux-pam/linux-pam/commit/dd9cf929e7ec79...