Now in concept, I’ve come up with a way to do this: When you start the disposable, pass it the name of your qube.
Then have the disposable send its own name back through qrexec.
However as a practical matter I haven’t been able to get it to work without either losing all other comm back from the disposable, or hanging. That’s probably just bash scriptsmanship, which I am still learning.
It can be done with the admin API.
Assuming you’re in a qube named foo and want to spawn (and communicate with) a new disp1234 qube, which will automatically be cleaned up when it shuts down:
readarray -d '' -s 1 disp < <(qrexec-client-vm dom0 admin.vm.CreateDisposable </dev/null)
wait $! || # handle error ...
qrexec-client-vm "$disp" admin.vm.Start </dev/null
qrexec-client-vm "$disp" myservice1+arg1
qrexec-client-vm "$disp" myservice2+arg2
qrexec-client-vm "$disp" admin.vm.Kill </dev/null
Which needs policy configuration like:
admin.vm.CreateDisposable + foo dom0 allow
admin.vm.Start + foo @tag:disp-created-by-foo allow target=dom0
myservice1 * foo @tag:disp-created-by-foo allow
myservice2 * foo @tag:disp-created-by-foo allow
admin.vm.Kill + foo @tag:disp-created-by-foo allow target=dom0
Note that a malicious foo qube might create thousands hundreds of (not yet started) disp1234 qubes, which will probably cause some problems…
Thank you for responding to this…As you can see I asked this question months ago–then again in a place where you got mentioned by name (and you responded there as well).
Anyhow, regarding your warning at the end, qubes already can start dispVMs albeit not knowing their name, so the malicious foo qube could also start a zillion qubes without this…or are you saying they’d all have the exact same name? Even so a malicious qube could do similarly that by generating identically-named named dispvms in a loop.
No I meant for a normal qrexec-client-vm @dispvm style launch the DispVM is created and started simultaneously, so that (or above that: however many qrexec requests are allowed to be in flight simultaneously) should put a low limit on nuisance creation of VM objects.
But I don’t know what happens if admin.vm.CreateDisposable creates thousands of VM objects in series, without starting them. Some things will probably slow down to a crawl, qubes.xml serialization might fail, etc.
Ah, gotcha.
I didn’t realize that create-and-start a disp VM was NOT an unsplittable atomic operation until now!
Such a DoS attack might actually just exhaust the range 1..254 (qubes.config.max_qid), at which point no new VMs of any type can be created - until those DispVMs are removed manually, or automatically during the next reboot.
I’ve bee already deploying this
[user@dom0 ~]$ qvm-tags disp4825 -v
audiovm-sys-audio
created-by-f36-min-adm-vm
disp-created-by-dom0
guivm-dom0
in a hope to prevent DoS attacks while disp4825 still would not be able to endanger other qubes not created by f36-min-adm-vm. Would this work?
I don’t understand. You’ve been deploying what to prevent DoS attacks?
Disposables are not created by adminVM, only their dvm-template is. Disposables based on such dvm-template are created by dom0. Or I misread and/or misunderstood what you wrote above?
What would be qvm-tags dispxxx from your example?
...
created-by-dom0
disp-created-by-foo
...
Your disp4835 has created-by- and disp-created-by- in the opposite way. How did you create it?
As I wrote, from f36-min-adm-vm which is obviously AdminVM, I created f36-min-adm-vm-DVM-template, which is obviously disposables template. I haven’t allowed neither to specifically created disposables through RPC policy, though.
Then, I just start dispVm in the the dom0 Q menu, for example, from the Disposable: f36-min-adv-m-DVM-template menu entry, since I ordered appmenus-dispvm 1 for it during creation
Ah ok. I guess in your setup, the equivalent DoS vector would be a malicious f36-min-adm-vm repeatedly calling one of the admin.vm.Create.* or admin.vm.CreateInPool.* methods to exhaust all qids.
Thanks a lot. That’s kind of promising since adminVM is offline anyway and was created by regular, official template and it is treated by me as any official template, so would have to have same level of “maliciousness” as template would have…
How can I modify this to create a disposable based on a specific disposable template?
The admin API docs (Admin API | Qubes OS) say that you should specify the target as the disposable template that you want to use, however this doesn’t seem to work. The docs are clearly outdated as they refer to a VM preference which no longer exists (dispvm_allowed). I think this is equivalent to the preference templatete_for_dispvms but even if I use a target that has this property set I don’t get a good result.
Is this possible?
Resolved myself. Needed to specify target=dom0 in the rule.
My other question is, is a disposable capable of learning its own name? And I guess as an extension, is any VM capable of learning its own name? It seems to me like the name is something that only exists in dom0 but @SteveC mentions a concept that requires the disposable to know it’s own name, I wonder if that ever became more than a concept?
$HOSTNAME is the name of the VM.
Of course as a user the hostname will often appear in a window’s title bar and in the command prompt if you’re looking at console/terminal
Unfortunately this isn’t the case in whonix vms.
I just fired up a Whonix qube (I don’t use it much, to be honest).
Title bar reads [disp9174] Whonix Welcome Page ___ Tor Browser. (I am using KDE; that could make a difference.)
But you are right in that at the command prompt in that qube the name (both in the prompt and echoing $HOSTNAME) is simply “host.” Nor is any other environment variable set to include (in this particular instance) 9174 so there might not be a way to figure this out.
This is probably to increase anonymity. Anyone asking their visitor for a hostname just gets “host” like all the other whonix/tor/whatever clients.
For the application I was working, unfortuntely, I expect to be running offline and so whonix wasn’t a consideration. Sorry about that.