Hmm, so one idea is that it may have been able to talk to some other piece of your desktop through the X socket? effectively causing a URL to be opened outside of the container?
You must be running Wayland with that X11 compatibility package that make it possible to use X11 in the container. It should not make a difference though with what we are discussion here.
Can you tell me what distribution you are running?
By following my tutorial, the host shares the X11 server socket with the container, meaning for example, that a malicious X11 app in the container can potentially perform all sorts of things on GUI apps on the host over the X11 Unix socket. Cannot access the memory of apps on the host, cannot access the filesystem of the host, but can access the Unix socket of X11.
Let’s run xdg-open in the container to open a URL. Here, there is no browser installed in the container, and this app will try to find the suitable application from within the container. So, it was probably not xdg-open.
ubuntu@steam:~$ xdg-open https://www.google.com
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: x-www-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: firefox: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: iceweasel: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: seamonkey: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: mozilla: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: epiphany: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: konqueror: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: chromium: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: chromium-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: google-chrome: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening 'https://www.google.com'
ubuntu@steam:~$
Nor with dbus-send which is used to instruct apps to perform things because they (host and container) do not share the socket at /var/run/dbus/system_bus_socket. There is no dbus-x11/dbus-launch installed either by default. You can also try with d-feet in the container to see if you can get any info that relates to the host.
Let’s go back to X11 and what can be gleaned out from the X11 Unix socket.
The following command, when you run it from within the container, will show the list of applications running on the host (and also container, like Steam).
xwininfo -root -tree
You can try to figure out how to instruct applications from within the container using a tool like xdotool, which uses the X protocol. By doing so, you can avoid writing an Xlib program instead.
We notice that there is a xdotool exec subcommand that instructions X11 to run programs.
Let’s run this in the container. It opens xeyes. Note that both the container and the host have xeyes.
xdotool exec /usr/bin/xeyes
Let’s try with something that exists on the host but not in the container. The container has no easy mechanism to run programs on the host.
$ xdotool exec /usr/games/gnome-sudoku
execvp failed: No such file or directory
Having tried all these, I think the important aspect is that only a malicious program would be able to perform bad things through the X protocol. I am sure that it is possible to build some sequence of commands to run code on the host. But I cannot think of a way for the steam client instructing the host to install Steam. In fact, Steam performs any update internally without prompting the user to download or run a program.
It would be helpful if you could describe the window that opened and prompted you to install Steam. It would be good to figure out whether it was Steam or something else that installed Steam on the host.
The typical commands like ps and top are not clear as to whether a process runs on the host or in a container. And in these gui containers, we have set the id mapping so that your user ID on the host matches that in the container. Therefore, the steam process appears to be running as your userid on the host but it is indeed running in the container. From the host you can view and even kill the processes that run in the container, but from inside the container you do not see the other processes from the host.
Having said that, you can use pstree which will show you the hierarchy of the processes.
What you need to look for, is that any Steam processes should be found only under the lxd process.
If you find a Steam process elsewhere in the process tree, then that’s a valid concern.