On Monday, December 16, 2019 at 5:33:52 PM UTC-5, Claudia wrote: > > brend...@gmail.com <javascript:>: > > Disposable VMs were not developed with anti-forensics in mind (e.g. no > protection in jurisdictions where you can be forced to hand over your drive > password > Never thought about it, but that makes sense. I can see how it would be > easy to confuse "non-persistence of malware" aspect and the > "non-persistence (non-remenance) of data" aspect, though. > > But then... What does the checkbox mean, "Keep dispVM in memory", under > global settings (R3.2, at least)? Screenshot attached. >
See: https://groups.google.com/d/msg/qubes-devel/QwL5PjqPs-4/JwcbdJDbBDwJ It was meant to be a dispVM speed-up option, not an anti-forensics option. > I sort of like the idea mentioned in bug #904, about doing the crypto > inside the dispVM itself, so that 1) the key is scrubbed by Xen when the > dispVM is shut down, and 2) data is non-recoverable instantly so you > don't have to wait until all dispVMs have been shut down for example. > Incidentally this approach actually offers a lot of improvement in > scenarios where the machine is seized while it's on and unlocked, too, > but that's another topic. > That could work, but depends upon threat model, e.g. if the dispVM hosts untrusted content then depending upon the VM to prevent leakage may have issues. > Just bouncing around some ideas. Seems like it might be possible to do > something like that, and perhaps simpler than the ephemeral pool > approach, depending on your situation. Thoughts? > I dunno...the ephemeral approach is simpler to me...in that it's just a bash script in dom0. It's less simple in usuage...in that it takes a while to run to get to a usable state. :) But it did help uncover some inefficiencies in the qvm-clone implementation that has been patched by the devs. In any case: the proof is testing data recovery during/after using the technique. e.g. With R4, I found that even after copying the disposable vm template and the template it is based off of to a new pool, on startup, at least one volatile volume per dispvm is created in the default pool. I'm pretty sure that's a defect and it's definitely a forensics gotcha. Hence the script currently needs to change the default pool before dispVM startup and then, after a time, reverts it back. Brendan -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/04f50bfa-c06c-4281-a4f5-f7cdf0702000%40googlegroups.com.
