2020-10-24 23:49:00
One of the benefits of teaching Linux to a group of young adults, is that it forces me to go back to the books myself. The Linux+ objectives cover a few things I haven't worked with yet (such as MDM), but also touches on things I haven't given much thought yet. Case in point: PAM.
Just about every Linux sysadmin certification exam requires that you can work with Pluggable Authentication Modules. They want you to make your SSHd or SU authenticates correctly, or to include pam_tally. So we learn about /etc/pam.conf and /etc/pam.d/* and how to setup an auth or session stack correctly.
What led me down a rabbithole was this: what if I want to make a Python app that authenticates users? I found references to python-pam and other modules, but most discussions ended with: "You need to run as root, or add your application user to the shadow group."
Initially this felt odd to me because, aren't we teaching everybody that services shouldn't run as "root"? In the end it does make sense, of course, because if any arbitrary user could (ab)use PAM to verify another user's password that'd be problematic. The process might be very noisy, but you could still try to brute-force the password.
One source of confusion was the pam_unix documentation, which states:
"A helper binary, unix_chkpwd(8), is provided to check the user's password when it is stored in a read protected database. This binary is very simple and will only check the password of the user invoking it. It is called transparently on behalf of the user by the authenticating component of this module. In this way it is possible for applications like xlock(1) to work without being setuid-root."
Stupidly my brain glossed over the important parts (I need sleep) and latched onto the "without being setuid-root". The important part being that it "will only check the password of the user invoking it".
What made me finally understand the workings of unix_chkpwd is a project of Marco Bellaccini's that I found on Github -> chkpwd_buddy. It should me the proper way of interacting with unix_chkpwd as a non-root user: FIFO pipes.
$ mkfifo /tmp/myfifo
$ echo -ne 'testing\0' > /tmp/myfifo &
$ /sbin/unix_chkpwd tess nullok < /tmp/myfifo
$ echo $?
0
$ echo -ne 'testing\0' > /tmp/myfifo &
$ /sbin/unix_chkpwd testaccount nullok < /tmp/myfifo
$ echo $?
7
$ sudo -i
# mkfifo /tmp/rootfifo
# echo -ne 'testing\0' > /tmp/rootfifo &
# /sbin/unix_chkpwd tess nullok < /tmp/rootfifo
# echo $?
0
# echo -ne 'testing\0' > /tmp/rootfifo &
# /sbin/unix_chkpwd testaccount nullok < /tmp/rootfifo
# echo $?
0
Root can verify both my "tess" password and the one on "testaccount", while I could only verify my own password with my normal account.
What's interesting, is that only the failed validation attempt shows up in journalctl. The successful attempts are not registered:
$ sudo journalctl -t unix_chkpwd
Oct 22 16:08:53 kalivm unix_chkpwd[86131]: check pass; user unknown
Oct 22 16:08:53 kalivm unix_chkpwd[86131]: password check failed for user (test)
To sum it up, if you want a Python app to authenticate the running-user's identity, you can use the python_pam module. But if you want the Python app to authenticate any/every user, then it will need to run as "root".
kilala.nl tags: teaching, work,
View or add comments (curr. 0)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.