Add support for starting gnome-terminal in a DispVM

[maxsu]

I've come across a curious little issue.

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

DispVM

---

Expected behavior:

The following command should start a DispVM and produce a working gnome-terminal, and allow the creation of a launcher for gnome terminal, similar to DispVM: xterm :

dom0 $ sh -c 'echo gnome-terminal | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'

Actual behavior:

The DispVM starts up and gnome-terminal may appear momentarily. If the terminal appears, it immediately terminates. After a moment the DispVM shuts down.

Dom0 terminal shows:

[dom0 ~]$ sh -c 'echo gnome-terminal | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'
time=1484435935.8, qfile-daemon-dvm init
time=1484435935.81, creating DispVM
time=1484435935.85, collection loaded
time=1484435935.85, VM created
time=1484435935.86, VM starting
time=1484435935.87, creating config file
time=1484435935.97, calling restore
time=1484435937.95, done
time=1484435937.98, done qubesdb
time=1484435937.98, resumed
time=1484435938.32, qrexec done
time=1484435940.26, guid done
time=1484435940.26, VM started
time=1484435940.27, reloading firewall
time=1484435940.28, starting VM process
[dom0 ~]$

The command finishes approximately 3 seconds after the last entry.

Steps to reproduce the behavior:

Execute the above command either in a dom0 shell or via a customized version of the 'xfce DispVM: xterm' launcher.

General notes:

I've used the qfile-daemon-dvm command to successfully launch other non-standard apps including the urxvt terminal and the nautilus, gedit, and gnome-calculator apps. I can successfully spawn gnome-terminal by using DispVM: xterm, and by using Qubes VM Manager's 'Run command in VM' dialog for an existing dispVM. Another person has been able to replicate the issue in their Qubes R3.2 environment.

---

[unman]

This is because gnome-terminal is a stub that calls gnome-terminal-server to open a new window and then exits. Because the command you have called exits, the dispVM closes. It's expected behaviour.

[unman]

This is because gnome-terminal is a stub that calls gnome-terminal-server to open a new window and then exits. Because the command you have called exits, the dispVM closes. It's expected behaviour.

[marmarek]

And this is also the reason why in default configuration there is xterm used, instead of gnome-terminal...

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

And this is also the reason why in default configuration there is xterm used, instead of gnome-terminal...

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[maxsu]

Thanks unman, I've verified that this is indeed what's going on. I found some more details in the second answer @here, and in the debugging instructions here.

Despite the technical difficulty, I think a user should reasonably be able to use gnome-terminal from a disp-VM. I've cobbled together a rather ugly solution:

sh -c 'echo /usr/libexec/gnome-terminal-server --app-id my.qubes.Terminal \& sleep 2 \&\& gnome-terminal --app-id my.qubes.Terminal | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'

I've tested this solution and it works to create a persistent gnome-terminal window. Additionally it correctly shuts down the dispVM once the last visible terminal window is destroyed (similar to the DispVM: Firefox use case), as this causes the gnome-terminal-server process to be destroyed.

I'm not entirely satisfied with this solution:

1. If gnome-terminal-server is slow to start for some reason (or if we remove the sleep invocation), we get an Error creating terminal: The name my.qubes.Terminal was not provided by any .service files
2. If a malicious process is able to persist the gnome-terminal-server beyond the point where all visible terminal windows have been closed, this would prevent shutdown of the dispvm, which might escape the attention of the user.

Since a process running in the shell could conceivably create a dummy display and send a terminal window to that display, item 2 seems like a risk that might not happen in the firefox case (where as far as I know firefox cannot simply execute arbitrary code in a privileged shell).

[maxsu]

Thanks unman, I've verified that this is indeed what's going on. I found some more details in the second answer @here, and in the debugging instructions here.

Despite the technical difficulty, I think a user should reasonably be able to use gnome-terminal from a disp-VM. I've cobbled together a rather ugly solution:

sh -c 'echo /usr/libexec/gnome-terminal-server --app-id my.qubes.Terminal \& sleep 2 \&\& gnome-terminal --app-id my.qubes.Terminal | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'

I've tested this solution and it works to create a persistent gnome-terminal window. Additionally it correctly shuts down the dispVM once the last visible terminal window is destroyed (similar to the DispVM: Firefox use case), as this causes the gnome-terminal-server process to be destroyed.

I'm not entirely satisfied with this solution:

1. If gnome-terminal-server is slow to start for some reason (or if we remove the sleep invocation), we get an Error creating terminal: The name my.qubes.Terminal was not provided by any .service files
2. If a malicious process is able to persist the gnome-terminal-server beyond the point where all visible terminal windows have been closed, this would prevent shutdown of the dispvm, which might escape the attention of the user.

Since a process running in the shell could conceivably create a dummy display and send a terminal window to that display, item 2 seems like a risk that might not happen in the firefox case (where as far as I know firefox cannot simply execute arbitrary code in a privileged shell).

[jpouellet]

2. If a malicious process is able to persist the gnome-terminal-server beyond the point where all visible terminal windows have been closed, this would prevent shutdown of the dispvm, which might escape the attention of the user.

This is not unique to gnome-terminal-server. For attacker-controlled DispVMs, there is no trusted correlation between all windows being closed and a DispVM being shut down. This is true irrespective of the initial program started.

[jpouellet]

2. If a malicious process is able to persist the gnome-terminal-server beyond the point where all visible terminal windows have been closed, this would prevent shutdown of the dispvm, which might escape the attention of the user.

This is not unique to gnome-terminal-server. For attacker-controlled DispVMs, there is no trusted correlation between all windows being closed and a DispVM being shut down. This is true irrespective of the initial program started.

[andrewclausen]

I think I have a systemd solution for this problem:

qvm-run '$dispvm' "gnome-terminal; systemctl --user start gnome-terminal-server --wait"

P.S. Sorry for spamming the mailing list. I should have checked here first.

[andrewclausen]

I think I have a systemd solution for this problem:

qvm-run '$dispvm' "gnome-terminal; systemctl --user start gnome-terminal-server --wait"

P.S. Sorry for spamming the mailing list. I should have checked here first.