[HN Gopher] The Sheer Terror of PAM
___________________________________________________________________
The Sheer Terror of PAM
Author : Tomte
Score : 63 points
Date : 2022-09-05 18:06 UTC (4 hours ago)
(HTM) web link (xeiaso.net)
(TXT) w3m dump (xeiaso.net)
| proto_lambda wrote:
| Title should be "PAM", not "Pam".
| nprecup wrote:
| I thought this was going to be about the show Archer.
| culturestate wrote:
| I thought I was about to read a study detailing the horrific
| long-term effects of using aerosolized non-stick spray for
| cooking.
| vk5tu wrote:
| 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(tm) was always Pam, not P.A.M.
| CottonMcKnight wrote:
| Solution: Let's reimplement PAM in systemd! That should make
| everyone happy.
| throw7 wrote:
| Isn't that SSSD? I don't know myself... just asking because
| sssd is a... daemon... or at least nominally one?
| marcosdumay wrote:
| 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.
| throwaway09223 wrote:
| 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.
| dale_glass wrote:
| I think that this is seriously a great idea.
|
| 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.
| OJFord wrote:
| I suppose it's sort of described by 'good opportunity for
| updating the API' - but my #1 reason would be 'you (need to)
| know systemd config anyway, so lets use it instead of a
| different thing'.
| GekkePrutser wrote:
| Aren't you re-inventing the SAML / OAuth wheel here? After
| all, running authentication as a service is precisely what an
| IDP does.
|
| But interesting option to bundle a micro IDP with the OS.
| Probably would make a lot of security sense _and_ every app
| using it would automatically work with a real IDP easily.
| krnlpnc wrote:
| Let's move the linux kernel and sshd into systemd while we're
| at it
| smitty1e wrote:
| See your kernel; raise you the whole data center.
| dale_glass wrote:
| You're joking, but I'm 100% serious.
|
| PAM is crusty and has a bad architecture. The fact that
| it's written in C, and is linked into another program as a
| library makes it impossible to fully isolate it from its
| host application, and exposes it to a myriad possible
| exploit points.
|
| Even wrapper binaries are not a great idea because of how
| UNIX works.
|
| fork() + exec() means the executed binary inherits a lot of
| state from the caller. Open files, signals, environment
| variables, chroot, mlock, resource limits, seccomp...
| there's a myriad of mechanisms that an executed binary can
| be exposed to, and even if it somehow perfectly takes all
| of them into account and defends itself against any
| possible malicious manipulation, the next kernel version
| could add a new one.
|
| That's why I think a sane, modern version of PAM should be
| a service and only communicate via a UNIX socket. That way
| you vastly reduce the attack surface, and allow locking up
| the PAM bits into their own, well defended box.
| throwaway09223 wrote:
| "The fact that it's written in C"
|
| The calling convention is C, but you can write PAM in any
| language.
|
| "and is linked into another program as a library makes it
| impossible to fully isolate it from its host application"
|
| Huh? You can never isolate the client side code. You will
| always have something in your app.
|
| "I think a sane, modern version of PAM should be a
| service and only communicate via a UNIX socket."
|
| So, write a module that talks to a socket. That's how
| like half of the PAM modules already operate. You will
| always have to have code in the application to talk to
| whatever oracle you're using. What you're describing here
| isn't any different from how PAM already works.
| dale_glass wrote:
| > Huh? You can never isolate the client side code. You
| will always have something in your app.
|
| Yes, and that "something" can be reduced to reads and
| writes to a socket.
|
| > So, write a module that talks to a socket. That's how
| like half of the PAM modules already operate.
|
| I mean move all of PAM to a service. So for instance
| currently chsh is a setuid application because it needs
| to be able to write to /etc/passwd. This is a requirement
| because the way it works is that it links to libpam,
| which will load a module, which will write to
| /etc/passwd, all inside the 'chsh' program.
|
| My suggestion would result in chsh becoming a completely
| unprivileged application that only deals with interfacing
| with the user, then passes the action to pamd, which
| would run with the required privileges.
| salawat wrote:
| You should look into GNU Hurd then.
|
| I'm being serious, as exactly what you're describing
| sounds an awful lot like their micro-kernel approach. At
| least as of the last time I looked into it.
| lukeh wrote:
| 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.
| csense wrote:
| I can't believe someone made a talk about PAM filled with memes
| and anime references and didn't include Obake PAM, the CEO vtuber
| [1].
|
| [1] https://www.youtube.com/c/ObakePAMCh
| xena wrote:
| Oh my god I didn't know that was a thing. I feel like I missed
| an amazing chance for shitposting. I'll be sure to get it next
| time!
| cryptonector wrote:
| I remember the OS/Net gatekeeper (gosh, I forget his name right
| this moment) getting up to write on a board that the way to spell
| PAM is SUX. Yup.
| YarickR2 wrote:
| Kids discover implementing security is complicated . News at 11.
| intsunny wrote:
| 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".
|
| [0] https://github.com/sa2ajj/pam-realm
| BiteCode_dev wrote:
| 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.
|
| Too bad, it's an interesting topic.
| xena wrote:
| Author here. Would my raw talk script without any of the visual
| aids I put in the talk be better here?
| omginternets wrote:
| Is there a video of the presentation somewhere? That would be
| ideal! Thanks
| xena wrote:
| The YouTube video is embedded in the page.
|
| https://youtu.be/BleS-MHLn7s
| smitty1e wrote:
| Outstanding, highly readable work. Double props for the Jenna
| Fischer photo.
|
| One suggestion might be putting hyperlinks in as either end
| notes or as anchor tags for those interested in chasing
| rabbits.
| jjjjoe wrote:
| Absolutely! I suspect it would also alleviate a couple of
| headscratchers like where you spelled out "underscore" when
| setting a breakpoint.
| xena wrote:
| Looks like I missed a sed command or two. I usually write
| out "underscore" in the script so I read it literally
| during recording: https://i.imgur.com/j3RdHA5.png
|
| I write out punctuation like underscore so that I know that
| is what I am literally saying to the camera. I usually edit
| that out. Apparently I missed out on that this time. Oops!
| Sorry. I'll put that on the checklist for next time (half
| considering making tests fail if I forget to do it).
| BiteCode_dev wrote:
| Yes, or just an option to hide the slides.
| xena wrote:
| Here:
| https://gist.github.com/Xe/400756b7d93f40b0b7ec48c65b7d066d
|
| I'll work on something more cohesive for the next talk.
| Sorry about this!
| skissane wrote:
| At least with this I can work out what your primary
| points are. The most important takeaway seems to be that
| OpenSSH sshd doesn't really use PAM unless you enable
| "ChallengeResponseAuth" config option, so if you want
| your custom PAM module to work with sshd, you need to
| turn that on.
|
| Another important point you make is, on Ubuntu, you need
| to download the debug symbol packages for systems
| libraries if you want gdb to give you meaningful
| backtraces.
|
| The suggestion of putting a breakpoint on dlsym also
| seems helpful.
|
| This meme-laden presentation style, I seem totally
| incapable of consuming or producing it, and I don't
| really get it. I don't know if it is a generational thing
| or something.
| adioe3 wrote:
| On the other hand, I found the slides wildly entertaining. To
| each his own.
| billyhoffman wrote:
| 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?
|
| Excellent content.
| betaby wrote:
| 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.
| somat wrote:
| 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.
|
| http://man.openbsd.org/login.conf#AUTHENTICATION
| jmclnx wrote:
| Well bsdauth it does stay out of your way :)
|
| I have had issues with PAM on Linux, FreeBSD and NetBSD, not
| many but some.
| hkgjjgjfjfjfjf wrote:
___________________________________________________________________
(page generated 2022-09-05 23:00 UTC)