Article can be summarized: "I didn't knew much about PAM, had random assumption and wasted a bit of time in the process". Not much of the substance unfortunately.
Yeah I was pretty disappointed, was hoping for something more. Most of the problems the author ran into had nothing to do with PAM. Things like "distributions compile PAM without debug logging" (annoying but common) and "PAM is a plugin system, so setting breakpoints is hard because dlsym() is used" (how else would you implement a plugin system in C, without requiring build-time foreknowledge of every plugin that exists?) and then some misconception that this is a "Java kind of thing" because Sun did it (when libdl predates Java and is by no means a Sun-specific thing, even though it was indeed first seen in SunOS).
It just felt like reading about someone who hasn't used C all that much, digging into a C-based project and discovering how some not-particularly-esoteric things are usually done in C ("function pointers aren't type-safe!") and then being surprised... and disgusted in a pretty "language elitist" way.
PAM is by no means an amazing piece of software. It has some baked-in assumptions that made sense 30 years ago that maybe don't so much these days. And it could be designed in a way that's more secure (though I expect you could reimplement PAM with better isolation while still keeping the API and flexibility). But it's... surprisingly not that bad, considering its age.
How can you "know much about PAM", though, other than getting very familiar with source code of PAM, the PAM modules and poorly-documented distro conventions? As the article mention, documentation is scarce, and I cannot agree more.
The article is at least showing how bad the situation is. I am rather familiar with various other aspects of Linux system administration, but PAM is a dark corner to me.
I found parts of it interesting, but I couldn't tell why the author [edited] was ascribing so many issues to be PAM's fault. Debugging dynamically loaded libraries, for example. Many things use dynamically loaded libraries, and it's not surprising PAM does so, given the need to be "pluggable".
Years ago, I’ve found an inverse correlation between emoji frequency and information quality. Anime is usually indicative as well, as is excessive use of imagery in general. All together are a dead give-away.
20'ish years ago I remember the original author of the `pam_realm` PAM module [0] writing the module becase "it was easier to work around PAM, than to understand what the fuck was happening inside of PAM".
The format of the article, and it's unwillingless to go to the point made me quit reading half way. Even in reader mode the flow of reading is interrupted every 2 lines by a large useless image or some snarky comment from the author.
It's a presentation in blog form. The images are the slides from presentation, the text is what Xe says. Perhaps you don't like this style of presentation?
PAM should be a service that communicates over an UNIX socket. Upsides:
* You can completely isolate it from anything else. Lock it into a sandbox. Use SELinux to ensure it doesn't do anything weird.
* Much more secure -- you have a very narrow communication channel, and no exposure to stuff like LD_PRELOAD.
* You avoid the mess of the above for the applications using it. Apps using PAM execute PAM code, and that means that anything that uses PAM needs to be able to do any arbitrary thing a PAM module might want to do.
* Applications using PAM no longer need to have root access. Your screensaver/lock screen can be completely unprivileged.
* If it can be an UNIX socket, it probably can also be a TCP socket, so you can have it run remotely if such a thing makes sense.
* The protocol can be inspected
* Good opportunity for updating the API and fixing anything lacking.
Actually the replacement for PAM is just ... regular software modules. "Implementing in systemd" would simply be making it non-modular. I'll explain:
The P in PAM stands for pluggable - as in, you can change the authentication modules your software is using without recompiling. You can configure sudo to authenticate against ssh_agent, against kerberos, against LDAP, and if systemd had an auth system it could talk to it too. You can also read and write passwords directly from the terminal, if one exists.
To "reimplement in systemd" would simply be to junk the Pluggable and Modularity aspects. You're left with a non-pluggable, single-use client library that talks to systemd. The interface would necessarily be limited, which has both good and bad aspects.
It would also always be possible to write a PAM plugin to talk to the same mechanism, but in a pluggable and modular fashion!
Anyway, this has been done a number of times already, such as with sssd. There of course isn't any need to make it part of systemd directly.
Actually, the Windows LSA architecture - where both verification of initial credentials (PAM) as well as network authentication (GSS) are remoted via IPC to a daemon - has a lot of nice properties. I believe sssd does something similar on Red Hat Linux.
While it is technically the obvious way to go, I just can't wait for the first time the systemd-pamd decides that no, it is working on the correct way, and every linux user that decided to upgrade to the last release-marked version should have ported all of their userland first to deal with the non-communicated change, not being able to log on their machines is their fault.
The openbsd auth system is interesting, I don't know if it is any safer than pam(it probably isn't) however because it operates across process boundaries instead of trying to dlopen everything in the same process it feels more human scale, that is, you feel you can actually debug and modify it without a Phd.
There's a trend that writing is for readers, rather than dictated by company PR. If you are writing for readers, then follow the usual rules for proper nouns where the word is a not-really-initialism which was never meant to be read as its individual letters. PAM™ was always Pam, not P.A.M.
That seems to be a bug with ethical ads. I've already escalated to upstream. Sorry about that! I literally didn't know that was a problem until yesterday. It worked before, something must have changed on their end.
[+] [-] betaby|3 years ago|reply
[+] [-] kelnos|3 years ago|reply
It just felt like reading about someone who hasn't used C all that much, digging into a C-based project and discovering how some not-particularly-esoteric things are usually done in C ("function pointers aren't type-safe!") and then being surprised... and disgusted in a pretty "language elitist" way.
PAM is by no means an amazing piece of software. It has some baked-in assumptions that made sense 30 years ago that maybe don't so much these days. And it could be designed in a way that's more secure (though I expect you could reimplement PAM with better isolation while still keeping the API and flexibility). But it's... surprisingly not that bad, considering its age.
[+] [-] ArchD|3 years ago|reply
The article is at least showing how bad the situation is. I am rather familiar with various other aspects of Linux system administration, but PAM is a dark corner to me.
[+] [-] tyingq|3 years ago|reply
[+] [-] hrbf|3 years ago|reply
[+] [-] kybernetyk|3 years ago|reply
[+] [-] bArray|3 years ago|reply
[+] [-] intsunny|3 years ago|reply
[0] https://github.com/sa2ajj/pam-realm
[+] [-] badrabbit|3 years ago|reply
[+] [-] BiteCode_dev|3 years ago|reply
Too bad, it's an interesting topic.
[+] [-] xena|3 years ago|reply
[+] [-] billyhoffman|3 years ago|reply
Excellent content.
[+] [-] adioe3|3 years ago|reply
[+] [-] CottonMcKnight|3 years ago|reply
[+] [-] dale_glass|3 years ago|reply
PAM should be a service that communicates over an UNIX socket. Upsides:
* You can completely isolate it from anything else. Lock it into a sandbox. Use SELinux to ensure it doesn't do anything weird.
* Much more secure -- you have a very narrow communication channel, and no exposure to stuff like LD_PRELOAD.
* You avoid the mess of the above for the applications using it. Apps using PAM execute PAM code, and that means that anything that uses PAM needs to be able to do any arbitrary thing a PAM module might want to do.
* Applications using PAM no longer need to have root access. Your screensaver/lock screen can be completely unprivileged.
* If it can be an UNIX socket, it probably can also be a TCP socket, so you can have it run remotely if such a thing makes sense.
* The protocol can be inspected
* Good opportunity for updating the API and fixing anything lacking.
[+] [-] throwaway09223|3 years ago|reply
The P in PAM stands for pluggable - as in, you can change the authentication modules your software is using without recompiling. You can configure sudo to authenticate against ssh_agent, against kerberos, against LDAP, and if systemd had an auth system it could talk to it too. You can also read and write passwords directly from the terminal, if one exists.
To "reimplement in systemd" would simply be to junk the Pluggable and Modularity aspects. You're left with a non-pluggable, single-use client library that talks to systemd. The interface would necessarily be limited, which has both good and bad aspects.
It would also always be possible to write a PAM plugin to talk to the same mechanism, but in a pluggable and modular fashion!
Anyway, this has been done a number of times already, such as with sssd. There of course isn't any need to make it part of systemd directly.
[+] [-] lukeh|3 years ago|reply
[+] [-] marcosdumay|3 years ago|reply
[+] [-] throw7|3 years ago|reply
[+] [-] somat|3 years ago|reply
http://man.openbsd.org/login.conf#AUTHENTICATION
[+] [-] matthews2|3 years ago|reply
[+] [-] jmclnx|3 years ago|reply
I have had issues with PAM on Linux, FreeBSD and NetBSD, not many but some.
[+] [-] csense|3 years ago|reply
[1] https://www.youtube.com/c/ObakePAMCh
[+] [-] xena|3 years ago|reply
[+] [-] proto_lambda|3 years ago|reply
[+] [-] nprecup|3 years ago|reply
[+] [-] vk5tu|3 years ago|reply
[+] [-] r00tbeer|3 years ago|reply
[+] [-] nn3|3 years ago|reply
[+] [-] xena|3 years ago|reply
[+] [-] cryptonector|3 years ago|reply
[+] [-] INGSOCIALITE|3 years ago|reply
[+] [-] xena|3 years ago|reply
[+] [-] nix23|3 years ago|reply
[+] [-] xena|3 years ago|reply
[+] [-] hoseja|3 years ago|reply
[+] [-] xena|3 years ago|reply
[+] [-] commandlinefan|3 years ago|reply
[+] [-] hkgjjgjfjfjfjf|3 years ago|reply
[deleted]
[+] [-] YarickR2|3 years ago|reply
[deleted]
[+] [-] arggies|3 years ago|reply
[deleted]