#8 Python environment

[Martin van Es]

I was just re-checking our pam-python test environment and I see some strange behaviour. My module used to work, but now throws an error it can't find any imported module in the auth.log, while running the code directly through python results in no (parsing) errors:

Mar 16 11:47:36 sandbox1 sshd[1981]: Invalid user student from 172.20.1.1 port 53182
Mar 16 11:47:36 sandbox1 /opt/pam-websso/pam_websso.py[1983]: Traceback (most recent call last):
Mar 16 11:47:36 sandbox1 /opt/pam-websso/pam_websso.py[1983]: File "/opt/pam-websso/pam_websso.py", line 2, in <module>
Mar 16 11:47:36 sandbox1 /opt/pam-websso/pam_websso.py[1983]: from OpenSSL import SSL
Mar 16 11:47:36 sandbox1 /opt/pam-websso/pam_websso.py[1983]: ImportError: No module named OpenSSL
Mar 16 11:47:36 sandbox1 sshd[1981]: Postponed keyboard-interactive for invalid user student from 172.20.1.1 port 53182 ssh2 [preauth]</module>

But invoking the pam_websso.py directly on the commandline results in no problems:
root@sandbox1:/opt/pam-websso# python pam_websso.py
root@sandbox1:/opt/pam-websso#

Why is module OpenSSL not available in pam_python context but is on the commandline?

(The same holds for any other module if I comment out OpenSSL import btw)

The pam configuration line:
auth sufficient pam_python.so /opt/pam-websso/pam_websso.py

[Martin van Es]

I was a bit rushed when reporting and forget to mention versions. We're testing on Debian Buster which ships libpam-python 1.0.6-1.1+deb10u1. The dependancy packages are all installed system-wide, as I don't/can't use a venv to run the pam module.

[Russell Stuart]

Is the PYTHONPATH defined in your clients environment? Off the top of my head that's the only thing that would effect how Python searchs for modules.

[Martin van Es]

root's environment doesn't contain PYTHONPATH, nor any reference to python as far as I can tell.

[Russell Stuart]

Lets go back to 1st principles. Run python -c 'import sys; print sys.path'. You will see a list of linux path's. Check that the OpenSSL directory exists in one of them. (Mine lives in /usr/lib/python2.7/dist-packages/OpenSSL/.)

Now do the same thing from your pam-python module. Eg: add import sys; import sys; open("/tmp/python-path.dbg", "w").write(repr(sys.path)) somewhere before you do import OpenSSL will suffice. If that tells you nothing, reply with both results.

[Martin van Es]

root@sandbox1:~# python -c 'import sys; print sys.path'
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages']

root@sandbox1:/opt/pam-websso# cat /tmp/python-path.dbg
['/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload']

Additionally this is inside a docker container, which starts systemd as PID1 (I call this a poor man's lightweight VM).

[Russell Stuart]

OK, so one of the 1st group must contain the directory OpenSSL containing the Python OpenSSL module. Evidently none of the directories in the 2nd group does.

Could you verify those two assumptions please.

If both are true you will have to speak to the person who created the conatiner about why that is so, and what can be done to fix it.

[Martin van Es]

Yes OpenSSL is in /usr/lib/python2.7/dist-packages as expected for a package installed using the package manager.

I built the container, and it's based on the ubiquitous default debian:buster image like this: FROM debian:buster and there's no python manipulation afterwards as far as I can tell.

I won't bother you with support on how to build a decent container, but you may be able to shed a light on what may give pam_python.so a different python environment than the ssh env I'm logged into?

I will try to create a genuine buster VM and see if I can reproduce the behaviour or not.

[Russell Stuart]

I think you have tripped over the fix for CVE-2019-16729, which is a local root exploit caused manipulating Pythons import path.

Try adding this to the top:

import site
site.main()

That undoes some of the mitigations the fix did. Sorry - I haven't seen it trip someone up before, so it's taken me a while to catch on.

[Martin van Es]

You're the hero!

cat /tmp/python-path.dbg 
['/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages']

And it works again. Many thanks!