Let’s say dom0 starts a disposable VM…one with the default disp-1234 naming scheme. (Unlocking a veracrypt container and making it available to other vms turns out to be a multi-step process.)
Can dom0 determine what number was appended, in the event s/he wants to communicate with it? Or otherwise have a “handle” to the DVM? Or is it purely “launch and forget”?
(Also applies to other qubes creating the disposable VM via qrexec. Since I might go that route instead.)
I know I could manage this with a named template (one for each veracrypt volume), but if I do that I’m likely going to end up a lot of them cluttering the manager, menus, etc. when they only should be dealt with by other pieces of the split-veracrypt schema.
This is good because I’m starting to get the suspicion that even though a “named disposable” is supposed to have no persistent state, it does anyway. Reusing the same name might not be terribly secure. (There appear to be files in dom0 for every qube that ever existed, including ones you thought were deleted.)
Of course with the unnamed disposables (disp1234) you will eventually reuse the same number by sheer happenstance.
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.
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:
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.
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.
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?
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.
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?