Xpra: Ticket #2085: pam auth bypassing account check

when using xpra with pam auth module it seems to be bypassing the account check.

we are using sssd with an account option to prevent access if users is not in a security group.

I have a test user teststev that is not in the group. this user cant ssh or use xrdp to connect to the system because they fail the pam_sss(xxx:account)

xrdp-sesman[4918]: pam_sss(xrdp-sesman:auth): authentication success; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=teststev
xrdp-sesman[4918]: pam_sss(xrdp-sesman:account): Access denied for user teststev: 6 (Permission denied)
xrdp-sesman[4918]: (4918)(139798234375168)[DEBUG] Closed socket 10 (AF_INET6 ::ffff:127.0.0.1 port 3350)

when using xpra it would be nice if this worked the same way to prevent users form gaining access to system.

xpra[8037]:  sending challenge for username 'teststev' using xor digest
python2[8037]: pam_sss(login:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=teststev
** login:auth success **
** no login:account ??
python2[8037]: pam_mail(login:session): pam_putenv: delete non-existent entry; MAIL
xpra[8037]: New ssl connection received from ::ffff:129.XXX.XXX.XXX, 39952, 0, 0 on :::14500
python2[9528]: pam_unix(xpra:session): session opened for user teststev by (uid=0)
python2[9528]: pam_unix(xpra:session): session opened for user teststev by (uid=0)
systemd[1]: Created slice User Slice of teststev.
systemd[1]: Starting User Manager for UID 16777562...
systemd-logind[724]: New session c7 of user teststev.
systemd[1]: Started Session c7 of user teststev.
systemd[9531]: pam_sss(systemd-user:account): Access denied for user teststev: 6 (Permission denied)
systemd[9531]: PAM failed: Permission denied
** systemd-user:account failed **
** ok this is good it should fail...
systemd[9531]: user@16777562.service: Failed to set up PAM session: Operation not permitted
systemd[9531]: user@16777562.service: Failed at step PAM spawning /lib/systemd/systemd: Operation not permitted
systemd[1]: user@16777562.service: Failed with result 'protocol'.
systemd[1]: Failed to start User Manager for UID 16777562.
python2[9528]: pam_systemd(xpra:session): Failed to create session: Start job for unit user@16777562.service failed with 'failed'
** looks like it failed...
** but still get a connection :(
xpra[8037]: Entering daemon mode; any further errors will be reported to:
xpra[8037]:   /run/user/16777562/xpra/S9511.log
xpra[8037]: Actual display used: :0
xpra[8037]: Actual log file name is now: /run/user/16777562/xpra/:0.log
xpra[8037]: proxy video encoders: none
xpra[8037]: new proxy instance started

Perhaps I'm just missing a configuration.. Any help on this would be nice.

Thanks!



Tue, 18 Dec 2018 14:51:00 GMT - steverweber:

Forgot to test the output before submitting.

Can an admin please reformat the issue (I don't see an option to edit what was sent).


Thu, 20 Dec 2018 01:11:17 GMT - Antoine Martin: owner, description changed

Please always include the command lines and version information (see wiki/ReportingBugs).

So it seems that you are using the system proxy with the "pam" authentication (aka "sys") module. The pam_auth.py module will do the pam check using the "login" service.

You can change this behaviour by setting:

(untested)

You can choose which service to use from the pre-defined services defined in /etc/pam.d, or even add a new one. The /etc/pam.d/xpra service file may or may not be suitable for you - it is used by the system-wide proxy server when starting as root and registering sessions with logind, see: #1105 for details.

If this works for you, please close this ticket as "invalid".


Thu, 20 Dec 2018 01:27:45 GMT - steverweber:

issue is not what pam.d/service xpra is using. tho that might be helpful to debug this (thanks)

the problem is more so that xpra failed the pam :account check but continues to give the user a xpra proxy connection.

i kinda have some notes in the middle of the first messages xpra log look for **

xpra failed the pam account check

systemd[9531]: pam_sss(systemd-user:account): Access denied for user teststev: 6 (Permission denied)
systemd[9531]: PAM failed: Permission denied

but

xpra[8037]: new proxy instance started

anyways i'll review the source and perhaps take time to dive in tomorrow.


Thu, 20 Dec 2018 02:28:41 GMT - steverweber:

this code does pam auth but seems to be missing the account check after auth. xpra/server/pam.pyx

i think after using pam_acct_mgmt.

pam : The pam_acct_mgmt(3) function is used to determine if the users account is valid. It checks for authentication token and account expiration and verifies access restrictions. It is typically called after the user has been authenticated. (in my case it checks if an user is a member of a group)

...

Sadly adding the check might cause backward compatibility issues if some people have bad pam account config.


Thu, 20 Dec 2018 02:58:51 GMT - Antoine Martin:

I think you may be getting confused between the two distinct pam calls:

It should be impossible to proceed if authentication has failed, though as per comment:2 you may want to use a different pam service to get the settings you want. You can test this separately from the proxy server:

xpra start :100 --bind-tcp=0.0.0.0: --tcp-auth=pam -d auth

(BTW, the command lines that you use are still missing from this ticket - so I am having to guess what you're doing here)

This one is optional and tries to register a logind session. If that fails the server will continue without. You can find more information on this in your server log. (again, it wouldn't hurt to attach it to this ticket)


Thu, 20 Dec 2018 06:17:08 GMT - steverweber:

thanks for all the help!

im using the default xpra systemd service on ubuntu 18.04 install.

TCP_AUTH=pam
AUTH=pam
ExecStart=/usr/bin/xpra proxy :14500 --daemon=no \
    --tcp-auth=${TCP_AUTH} \
    --ssl-cert=/etc/xpra/ssl-cert.pem --ssl=on \
    --bind=none --auth=${AUTH} --socket-dirs=/run/xpra --socket-permissions=666 \
    --log-dir=/var/log --pidfile=/run/xpra.pid --debug=${DEBUG}
I also needed to chmod 0777 /run/xpra to workaround some permission issue.. but never mind that.

then connecting to the http5 webclient to make the connection. ...

tomorrow i'll change xpra to use a custom pam.d/service with extra debugging.

sorry in advance if how pam does this auth,account,session stuff is already known to you.. i just want to be sure we are on the same 'page'.

It should be impossible to proceed if authentication has failed,

true... but authentication is not the issue. account authorization is the issue.

in pam ​https://linux.die.net/man/3/pam_authenticate is used to check if a user is who they say they are. No issue with this. (teststev is a valid account.. we have >30k accounts but only some are allowed to use the server)

where ​https://linux.die.net/man/3/pam_acct_mgmt checks to ensure the user is allowed to use the resource. (teststev should be denied access because not in a security group..)

since i dont see a call out to pam_acct_mgmt in the the xpras pam code.. i suspect that might be the issue... still vary likely the issue is on my end, i often miss the more simple things :)

thanks


Thu, 20 Dec 2018 06:50:01 GMT - steverweber:

anyways i'll likely just add something like this to the top of a custom pam service

auth required pam_succeed_if.so debug user ingroup magicadmin

this should block the auth for unprivileged accounts.


Fri, 21 Dec 2018 06:26:34 GMT - Antoine Martin: status changed; resolution set

You can also try r21254 or later with either:

Enabled -d auth for more details.


Fri, 21 Dec 2018 14:46:17 GMT - steverweber:

thanks for the fast work!


Sat, 23 Jan 2021 05:41:49 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2085