xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#2085 closed defect (fixed)

pam auth bypassing account check

Reported by: steverweber Owned by: steverweber
Priority: major Milestone: 2.5
Component: server Version: 2.4.x
Keywords: pam Cc:

Description (last modified by Antoine Martin)

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

  • ubuntu 18.04
  • using pam as auth through sssd (AD)
  • xpra mostly default setting

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!

Change History (9)

comment:1 Changed 3 months ago by 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).

comment:2 Changed 3 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to steverweber

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:

  • the "service" option, ie: for tcp and system-auth:
    xpra proxy --tcp-auth=pam,service=system-auth
    
  • the environment variable 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".

comment:3 Changed 3 months ago by 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.

comment:4 Changed 3 months ago by steverweber

this code does pam auth but seems to be missing the account check after auth.

https://xpra.org/trac/browser/xpra/trunk/src/xpra/server/pam.pyx

i think after using

https://linux.die.net/man/3/pam_authenticate

this check should be done.

https://linux.die.net/man/3/pam_acct_mgmt

https://linux.die.net/man/3/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.

Last edited 3 months ago by steverweber (previous) (diff)

comment:5 Changed 3 months ago by Antoine Martin

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

  • the first one is for authentication if that's what you configured.

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)

  • the second one is for logind and uses the "xpra" service.

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)

comment:6 Changed 3 months ago by 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

comment:7 Changed 3 months ago by 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.

Last edited 3 months ago by steverweber (previous) (diff)

comment:8 Changed 3 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

You can also try r21254 or later with either:

  • env var:
    XPRA_PAM_CHECK_ACCOUNT=1 xpra start --bind-tcp=0.0.0.0: --tcp-auth=pam
    
  • pam authentication module option:
    xpra start --bind-tcp=0.0.0.0: --tcp-auth=pam,check-account=yes
    

Enabled -d auth for more details.

comment:9 Changed 3 months ago by steverweber

thanks for the fast work!

Note: See TracTickets for help on using tickets.