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!
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).
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:
tcp
and system-auth
:
xpra proxy --tcp-auth=pam,service=system-auth
XPRA_PAM_AUTH_SERVICE
. ie:
xpra proxy --env=XPRA_PAM_AUTH_SERVICE=system-auth ...
(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".
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.
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.
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)
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
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.
You can also try r21254 or later with either:
XPRA_PAM_CHECK_ACCOUNT=1 xpra start --bind-tcp=0.0.0.0: --tcp-auth=pam
xpra start --bind-tcp=0.0.0.0: --tcp-auth=pam,check-account=yes
Enabled -d auth
for more details.
thanks for the fast work!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2085