xrdp from restricted container (singularity/apptainer)

[andreasplesch]

Our cluster environment offers use of singularity containers ( https://docs.sylabs.io/guides/3.10/user-guide/ ) which have more restrictions than docker containers. Our group would want to use xrdp to enable GUI apps from cluster nodes, and is figuring out ways to deal with the container restrictions.

While we were overall successful, eg. it works in a somewhat hacky way, there are some remaining questions for which any feedback would be much appreciated. Let me list them in the order they were encountered.

1. no systemd or init.d service support: sudo or root or even su user from within the container is not possible. Only the 'outside' user is available at runtime. This means the regular way to launch xrdp as a service daemon cannot be used. I ended up using:

    #systemctl start xrdp
    #systemctl status xrdp
    #whoami
    #service xrdp status
    #service xrdp start
    #service xrdp status
    nohup xrdp --nodaemon &
    DISPLAY=:10 xrdp-sesman --nodaemon

following #1360. Is that equivalent to what the service scripts would do ? The nohup back-grounding was necessary because otherwise xrdp-sesman would not start (or start but stop xrdp). Using xrdp without --nodaemon would not work, and I am not sure why. Should xrdp-sesman --nodaemon also be put in the background ?

2. permission/ownership of /etc/xrdp/*: Presumably due to the need of starting xrdp as regular user and following Black screen when xrdp-sesman process is non root - SOLVED #1360 it was also necessary to allow access to these files:

    chmod -R 777 /etc/xrdp

Presumably, this is too open but this is only accessible from within the container which is owned by the user. Probably it is safer to change the owner instead to the $USER but cannot be done by the user. Just read permissions for all should suffice (444) ? Let me try that.

3. logging: Since /var/log/ is not writable to users, just log to /tmp:

    sed -i 's=/var/log/=/tmp/=' /etc/xrdp/sesman.ini
    sed -i 's=/var/log/=/tmp/=' /etc/xrdp/xrdp.ini

This works fine. auth.log is normally generated by syslog from PAM but pam from the container uses the system syslog which is configured to log remotely. I could not find a way to have pam log somewhere else, eg. not use syslog. Is there a way ? I know this is a pam question not a xrdp question. It would have been mostly helpful for problem tracking.

4. Authentication: Probably due the way singularity handles users, we had to disable PAM authentication and account checking:

    sed -i 's/security_layer=tls/security_layer=negotiate/' /etc/xrdp/xrdp.ini
    sed -i 's/@include common-auth/auth required pam_permit.so/' /etc/pam.d/xrdp-sesman
    sed -i 's/@include common-account/account sufficient pam_permit.so/' /etc/pam.d/xrdp-sesman

And, in deed this allows for connecting without any or the wrong password (after establishing the ssh tunnel). This is not great but perhaps less problematic since the ssh tunnel still needs to be made, and the connection can only be made from one localhost. I have to experiment with the tls security layer but for regular users creating certificates may be too hard. Any suggestions most welcome.

Missing account checking is mostly a problem if the user name is mistyped. Then the connection is still established but there is no home directory, and the session manager gets confused and there is a black screen.

5. XSession: AFAIU xrdp relies on pam.d/common-session to use systemd to start dbus for session management: man pam_systemd although how dbus is related is not quite clear to me. In the container, systemd cannot be used. Accordingly, I could not figure out how to replace that step with something else. It seems to involve mostly creating /run/user/$UID and setting the $XDG_SESSION_ID to something. Instead, I ended up with creating a $HOME/.xsession file with:

dbus-launch --exit-with-session /usr/bin/xfce4-session

The dbus-launch command seems to do the right thing. Is there a better way to replace pam_systemd ? In addition, it would be much preferable to preconfigure the container, eg. xrdp, rather than doing this for each user. Where would be the appropriate place for this ? /etc/xrdp/startwm.sh ? What is the recommended way to use xrdp without systemd ?

Thanks for reading and any feedback.

[matt335672]

Hi @andreasplesch

1. xrdp runs on other system other than systemd ones. Other files are available in the source distribution in the instfiles directory. Some of these may be better suited to your container. I suggest you take a look at those. I don't understand why --nodaemon should be giving you trouble.
2. Read-only access to /etc/xrdp should be adequate.
3. I think pam logging uses syslog, and that's it. A lot of the modules use pam_syslog() and that's just a wrapper around syslog. Your only option would be to change where syslog sends LOG_AUTHPRIV messages.
4. You'll need to use some sort of PAM authentication module if you want the password checking to work. xrdp doesn't support client certificates, as far as I am aware.
5. xrdp doesn't understand dbus or systemd at all - it just runs the /etc/xrdp/startwm.sh script. That calls other system-specific scripts. In a container environment those system-specific scripts may not work at all well, so you may be best off replacing /etc/xrdp/startwm.sh with something which just starts the desktop of your choice.

Other comments:-

1. We don't test xrdp-sesman without root privileges. If it works, that's great but it's not designed to support that move of operation.

I hope that's of some use.

[andreasplesch]

Thanks. These points are very helpful, to find out what we may have missed.

ad 1. I will give not using --nodaemon another try.
ad 2. About Happy to confirm readonly permissions suffice.
ad 3. The syslog configuration is locked down. Not an issue for users anyways.
ad 4. If passwords are ignored, is there a way to avoid prompting for a password ? Maybe a start up script can generate user specific .ini files for xrdp and sesman. I think there is an option to point to the location of the .ini files.
ad 5. Ok. Let me edit or replace the startwm.sh script. It does look like that using common-session include in pam.d/xrdp-sesman introduces a dependency on systemd via the pam_systemd module. I see that this happens only on debian and suse. Other platforms use other session pam modules. So I can try to experiment a bit more there.

xrdp-sesman seems to work well enough non-privileged. It is probably best to keep using it. But is there a way to run xrdp without xrdp-sesman ?

[andreasplesch]

ad 1. Running xrdp and xrdp-sesman without --nodaemon as regular user from within the instance fails silently. sesman is not supported.

The last lines of strace are:

> strace xrdp
...
penat(AT_FDCWD, "/var/run/xrdp.pid", O_RDWR|O_CREAT, 0600) = -1 EROFS (Read-only file system)
openat(AT_FDCWD, "/var/run/xrdp.pid", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/zoneinfo/UTC", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 3545
lseek(4, -2261, SEEK_CUR)               = 1284
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 2261
close(4)                                = 0
write(3, "[20220708-13:50:27] [CORE ] runn"..., 89) = 89
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

> strace xrdp-sesman
...
penat(AT_FDCWD, "/var/run/xrdp.pid", O_RDWR|O_CREAT, 0600) = -1 EROFS (Read-only file system)
openat(AT_FDCWD, "/var/run/xrdp.pid", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/zoneinfo/UTC", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=3545, ...}) = 0
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 3545
lseek(4, -2261, SEEK_CUR)               = 1284
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 2261
close(4)                                = 0
write(3, "[20220708-13:50:27] [CORE ] runn"..., 89) = 89
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

[matt335672]

OK - that make sense.

Without --nodaemon, both processes are unable to write their PID files.

[e-kotov]

@andreasplesch, have you succeeded with running a container with XRDP?

[andreasplesch]

Hi there. Yes, I think I got it working but it seemed quite far off the supported configuration and fragile. In the end we switched to Turbovnc since the users were comfortable with installing and using the Turbovnc client both on Windows and Macs. So if vnc is an option, I would suggest looking into it since it is easier to setup for singularity.

[e-kotov]

@andreasplesch Thanks for the quick response! So with VNC you did not have issues with admin/root?

[andreasplesch]

No, I do not think there are issues with vncserver and root. Here is a relevant excerpt for singularity configuration.

%environment
    export LC_ALL=C
    export TVNC_PORT=${TVNC_PORT:-':1'}

%runscript
    echo "Container was created $NOW"
    echo "Arguments received: $*"
    echo "$@"
    #systemctl start xrdp
    #systemctl status xrdp
    #service xrdp status
    #service xrdp start
    #service xrdp status
    whoami
    #nohup xrdp --nodaemon &
    #DISPLAY=:10 xrdp-sesman --nodaemon
    unset XDG_RUNTIME_DIR
    if [ $# -gt 0 ]; then
      TVNC_PORT=$1
    fi
    echo "Using vnc port $TVNC_PORT"
    vncserver -fg -geometry 1920x1200 -wm xfce4-session $TVNC_PORT