Insane Puzzle: why does "qvm-open-in-vm $dispvm https://google.com" work, but "qvm-open-in-vm $dispvm https://google.com" not work?

User Support 4.1
#1

If you try creating the following program qvm-open-in-vm-we.py:

#!/usr/bin/env python3
import os

os.execvp("qvm-open-in-vm", ["qvm-open-in-vm", "$dispvm", "https://google.com"]);

then run it, it opens https://google.com in a disposable (as one would expect)

However, it’s also possible to run it and get a insane result if one tries running it from inside firefox, via installing https://github.com/raffaeleflorio/qubes-url-redirector/, then replacing /opt/qubes-url-redirector/qvm-open-in-vm-we.py with the new version above.

The result when selecting “open in disposable” from inside firefox is that it opens a disposable VM, but the disposable does not open a webbrowser! It just sits there consuming memory.

It can’t be a parameter problem because the parameters are statically set in the .py file to $disp and https://google.com, and the function is obviously being called as it starts the VM. So what could the difference possibly be?

Another clue is that this is a new problem with 4.1, that did not happen in 4.0 .

Are there ways to get logs of what qvm-open-in-vm is trying to do differntly?

#2

Got the same result :confused:

1 Like
#3

Crazy, isn’t it?

1 Like
#4

My guess would be failed access to /dev/xen/* files from within firefox. Is extension running in some kind of sandbox? Or maybe firefox is limited with an apparmor profile?

#5

Hey! Thanks for answering on a saturday.

I’m familiar with selinux commands, but not apparmor commands so I’m going to be excessively detailed in my descriptions so you can tell me if I"m doing something wrong.

First, checking the file permissions:

root@work-internet-github:/var/log# ls -l /dev/ | grep xen
drwxr-xr-x 2 root root         160 Jun 24 15:12 xen
root@work-internet-github:/var/log# ls -l /dev/xen/
total 0
crw-rw---- 1 root qubes 10, 59 Jun 24 15:12 evtchn
crw-rw---- 1 root qubes 10, 58 Jun 24 15:12 gntalloc
crw-rw---- 1 root qubes 10, 57 Jun 24 15:12 gntdev
crw-rw---- 1 root qubes 10, 55 Jun 24 15:12 hypercall
crw-rw---- 1 root qubes 10, 56 Jun 24 15:12 privcmd
crw-rw---- 1 root qubes 10, 62 Jun 24 15:12 xenbus

Logs:
The string “apparmor” does not appear in /var/log, nor does anything seemingly relevant which would be around the times of attempts.

I doubt this type of message in /var/log/xen/ of dom0 is relevant:
xen:grant_table: g.e. 0x3121 still pending

Then tried:
sudo systemctl stop apparmor.service
tried it again and got the same result.

Also, i don’t know how the firefox isolation works, but i believe it uses multiple processes now.

Is there any way to tell if the parameters "$dispvm", "https://google.com" are making it to dom0?

#6

Regarding firefox, “sandbox” makes me think of the isolation they’ve been talking about. I found something that talks about “new” firefox isolation, but it looks like it’s not implmented in 91, as going to about:config and searching for fission.autostart results in “false”. (process gotten from this document: Introducing Site Isolation in Firefox - Mozilla Security Blog)

Of interest, notes on firefoxes isolation stragery are here Introducing Firefox's new Site Isolation Security Architecture - Mozilla Hacks - the Web developer blog
and here is notes on their isolation that are way too new to have a chance of being in 91
Improved Process Isolation in Firefox 100 - Mozilla Hacks - the Web developer blog

#7

Yes, take a look at journalctl in dom0. But since the DispVM starts, that’s most likely not it.

BTW, you may want to use new syntax: @dispvm

#8

It’s not insane, it’s user profiles -
Use

os.execvp("sudo", ["sudo", "-u", "user", "qvm-open-in-vm", msg["vmname"], msg["url"]] );

for the call from firefox.

1 Like
#9

Solved! Thanks so much for figuring this out unman.
(he also submitted a pull request solving the issue upstream: ( 4.1 compatibility? · Issue #43 · raffaeleflorio/qubes-url-redirector · GitHub))

1 Like
#10

BTW, I think there might be a typo or something in the title, because the two quoted strings are identical character-for-character.

#11

actually that was not a typo. Thats what made it so insane :slight_smile:

It’s resolved now though