[HN Gopher] The Surreal Horror of Pam
___________________________________________________________________
The Surreal Horror of Pam
Author : todsacerdoti
Score : 62 points
Date : 2021-11-09 21:13 UTC (1 hours ago)
(HTM) web link (christine.website)
(TXT) w3m dump (christine.website)
| gerdesj wrote:
| PAM is quite something. Normally you ignore it and it quietly
| gets on with the job. Then one day you find yourself deploying
| something like this on your laptop: %PAM-1.0
| auth required pam_faillock.so preauth
| auth [success=3 default=ignore] pam_unix.so
| try_first_pass nullok auth [success=2 default=ignore]
| pam_winbind.so -auth [success=1 default=ignore]
| pam_systemd_home.so auth [default=die]
| pam_faillock.so authfail auth required
| pam_permit.so auth required pam_env.so
| auth required pam_faillock.so authsucc
| -account [success=2 default=ignore] pam_systemd_home.so
| account [success=1 default=ignore] pam_winbind.so account
| required pam_unix.so account optional
| pam_permit.so account required
| pam_time.so -password [success=2 default=ignore]
| pam_systemd_home.so password [success=1 default=ignore]
| pam_winbind.so password required
| pam_unix.so sha512 shadow password optional
| pam_permit.so session required pam_limits.so
| session required pam_unix.so session required
| pam_winbind.so session optional pam_permit.so
|
| The syntax is quite terse and like nothing else. No idea why it
| insists on wasting characters though. auth could be au, account:
| ac, password: pa and session: se. Why on earth put pam_ on the
| front of the modules and .so on the end. Tut!
|
| The winbind stuff is configured elsewhere in several places -
| /etc/samba/smb.conf and /etc/security/pam_winbind.conf
| (obviously).
|
| In general it is good enough to keep a spare virtual console
| logged in as root whilst you play with PAM. Otherwise get some
| experience with say Gentoo and Arch and the like. Then you will
| have rather good system rescue skills. Keep a System Rescue
| CD/USB to hand ... boot, mount /, /boot, /dev, /sys etc, chroot
| ... fix whatever you broke and then reboot. Rinse, repeat. Or
| spin up a VM and snapshot/checkpoint it before experimenting.
| notyourday wrote:
| > Why on earth put pam_ on the front of the modules and .so on
| the end
|
| Because it uses dynamic linking of the shared libraries used
| for authentication.
| gerdesj wrote:
| I was being facetious.
|
| The config file doesn't need to worry about the nuts and
| bolts. All of the PAM modules are named pam_xxxxx.so so the
| configuration file only needs to specify the name, ie the
| xxxxx. Also some parts of the configuration are abbreviated,
| eg: auth and other bits are not, eg: password.
|
| Those "[success = n" things mean "skip this number of lines
| if this invocation succeeds. It's a pretty mad "if f(x) ==
| true goto n" statement.
|
| Begrudgingly I have to say that despite the oddness of it
| all, it is reasonably easy to follow what is going on when
| you understand the rules.
| [deleted]
| Spivak wrote:
| And the best part is that it supports conditional logic with
| goto's! [success=3] mean's jump three rules ahead. Which means
| you can't really modify this file without considering the whole
| thing.
|
| This led Ubuntu to create /usr/share/pam-configs which have
| files like Name: SSS authentication
| Default: yes Priority: 128 Auth-Type:
| Primary Auth: [success=end
| default=ignore] pam_sss.so use_first_pass Auth-
| Initial: [success=end default=ignore]
| pam_sss.so forward_pass Account-Type: Additional
| Account: sufficient
| pam_localuser.so [default=bad success=ok
| user_unknown=ignore] pam_sss.so Session-Type:
| Additional Session-Interactive-Only: yes
| Session: optional
| pam_sss.so Password-Type: Primary Password:
| sufficient pam_sss.so use_authtok
| Password-Initial: sufficient
| pam_sss.so
|
| to try and make something declarative. RHEL/CentOS went the
| authconfig route but both ended up saying to never ever touch
| anything in /etc/pam.d
| xena wrote:
| Wait, is this why my arbitrary changes to /etc/pam.d on
| Ubuntu have resulted in failure?
| Spivak wrote:
| Maybe! Rewriting PAM is usually only done when messing with
| packages but can be called manually if you drop files in
| there with your config management.
|
| "Wow this could be really useful" you might think. "Where
| "is it documented?"
|
| https://wiki.ubuntu.com/PAMConfigFrameworkSpec
|
| "But where is the reference, how do I know what directives
| are even available?"
|
| ...
| notyourday wrote:
| > because /etc/passwd is world-readable by design for some arcane
| reason that I can't find on Google
|
| It is pretty comical when people who do not know basics of how
| the system permissions work wax about authentication and
| authorization used by the same systems.
| lmilcin wrote:
| Especially when it is not an arcane reason at all.
|
| There was a time when it was considered ok to have the salted
| and MD5-hashed password available to all users.
|
| Then people learned to bruteforce the password and so the hash
| itself was moved to shadow file but passwd was left because a
| lot of platform software and scripts depended on it.
|
| This may shock people nowadays but back then this was fine. I
| remember having to explain to the users (and sometimes loosing)
| the need to have a password at all.
| [deleted]
| xena wrote:
| I'm the author of the talk if you have any questions. This was a
| fun talk to write, easily one of my favorites.
| a-dub wrote:
| i like this post, both style and content. only thing missing
| would perhaps be a small reference to nis, nis+ and netinfo which
| were early attempts to build distributed and centrally controlled
| databases for /etc stuff and ye old faithful which i always
| preferred for production systems which was to rsync flatfiles out
| for maximum reliability.
|
| not sure if i totally agree with the immutability argument for
| /etc, but i suppose that's more about protecting against errant
| devs abusing sudo privs to do weird things rather than securing
| things against malicious actors.
| kps wrote:
| > _because /etc/passwd is world-readable by design for some
| arcane reason that I can't find on Google_
|
| Because it maps user IDs to names so that you can see names in
| `ls -l` and `who` and such.
| throwawayboise wrote:
| And the sensitive parts were split off into the root-only
| /etc/shadow a long time ago.
| Spivak wrote:
| I mean anything that happened in the 90's seems to be
| considered "yesterday" in computing history terms.
| Spivak wrote:
| But that doesn't really answer the question. Nothing was really
| stopping a setuid program from granting access to the non-
| sensitive bits of the passwd/group files.
| p_l wrote:
| Efficiency (spawning setuid program for every line printed by
| ls -alv is a bit too much), and you don't want to make too
| privileged programs too (suid ls?)
| Spivak wrote:
| I mean the hypothetical program would have just dumped the
| whole file minus the sensitive bits.
| mindwok wrote:
| Exposing a setuid program that prints the file would be
| more dangerous though. The result is the same (you can
| read /etc/passwd) except now you have a vector for
| gaining root access through an exploit to this setuid
| program.
| notacoward wrote:
| Also things like "finger" looking up their home directory and
| showing you their .plan file. Not saying it was a _good_ choice
| then, let alone now, but the number of Chesterton 's Fence
| violations in this presentation is pretty high.
| lexicality wrote:
| > the number of Chesterton's Fence violations in this
| presentation is pretty high
|
| The article's tagged as satire, I'm not sure you should be
| expecting good logic and sources
___________________________________________________________________
(page generated 2021-11-09 23:00 UTC)