Very spontaneous idea here (untested): How about loop mounting the vmdk from within the host, using the host (or its usb interface) to rsync or tar the data/config.
Hm, the way back head scratching … Is a loop mounted vmdk writeable? If so (most likely negative though) we could rsync or tar the backup into the new system, boot, done.
As I said: a very spontaneous (not deliberated) idea. Shooting from the hip.
This is correct. I am afraid to say, no improvement is on the horizon. Help is welcome.
[quote=“Cerberus, post:1, topic:207”][quote author=JasonJAyalaP link=topic=105.msg760#msg760 date=1393721362]
The difficulty of moving your data (and even the images themselves) around is a sore spot in Whonix user experience right now. VirtualBox using closed source drivers for their usb support is especially frustrating. Having a better answer for all this will be an important milestone for Whonix.
[/quote]
Very spontaneous idea here (untested): How about loop mounting the vmdk from within the host, using the host (or its usb interface) to rsync or tar the data/config.
Hm, the way back head scratching … Is a loop mounted vmdk writeable? If so (most likely negative though) we could rsync or tar the backup into the new system, boot, done.
As I said: a very spontaneous (not deliberated) idea. Shooting from the hip.[/quote]
Possible in theory, but there is only a non-free implementation of write access to vmdk images. I aggregated my attempts on finding a solution for this on this page:
We can’t deploy vdi or raw by default in .ova’s. VirtualBox does not support that. This is bad.
You can get your data out of an existing vmdk. But you need VBoxManage to convert to vdi first. You could then manipulate your image, add files, remove files etc. Even boot it again, but then you’d need to dispatch detach the vmdk from the VM first and then attach the vdi. Perhaps it would be best if everyone did that before using Whonix. Cumbersome approach. This is bad.
Mouting vmdk isn’t possible using Free Software. (At least not in Debian Jessie. There might be a solution that works in Wheezy but will break in Jessie since support was terminated. (Named virtualbox-fuse.) This is bad.
Whatever I attempted to fix this, I hit a wall. Unfortunately, I am not skilled to create a Free Software vmdk read/write mount driver. This is bad.
Eventually, when Whonix KVM support has been finished, mounting images gets simpler. But only for Linux users. (KVM is Linux-only.) And installing Whonix in KVM is more difficult than importing an .ova into VirtualBox, because KVM does not have a VM import feature. This is bad.
Whonix based on QubesOS could make file transfer and backups really safe and simple. But it will take a long time until we get there. Not everyone will be willing or able (hardware issues) to install QubesOS. This is bad.
While these are a lot of “this is bad”, it’s also motivating from my perspective.
Some thoughts:
vmdk loop-mounting
a) thanks for providing lots of insights, i.e. sharing your research. do you think research is exhausted here already?
b) from my perspective, if we’d come up with a solution for Linux-only, that would be at least one step forward. From my very own perspective, we should anyways promote Linux-only as a host OS, considering the goals of the project. Windows/Mac hosts are not suitable for a serious Whonix setup.
virtualization solutions
I can’t stress enough that we should anyways focus on the lowest common denominator here. Think about (so called) “developing” countries. They don’t have Quad-Core processors and lots of Ram, Sata Drives, lots of Bling Bling. That’s the reason I’m such engaged in LowFat Whonix btw. They have Pentium 4 machines, 1 GB Ram, IDE drives. If we provide some reasonable performance on these > awesome! And also: Such a LowFat Whonix shines on a “developed” world machine too. Afaik, KVM urgently needs hardware virtualization, same for Qubes OS(?). If we concentrate on these exclusively, we’re cutting off 2/3 of the world’s population. Just my 0.02 $.
do you think research is exhausted here already?Mine is. A fresh mind may come up with better results.
if we'd come up with a solution for Linux-only, that would be at least one step forwardSure.
we should anyways promote Linux-only as a host OS, considering the goals of the project. Windows/Mac hosts are not suitable for a serious Whonix setup.Sure, just keeping support for them builds a bridge for them to the Linux world. (I personally got involved into Linux because I used it inside VMs for a long time.)
I am not so sure. There are statements oposing guest addtions and there are statements oposing these statements and I am not qualified to determine what is true. (Linked on https://www.whonix.org/wiki/VirtualBox_Guest_Additions) (Please open another topic if you like to discuss security of guest additions in details.)
Patrick, why not use the guest additions shared folders once for that purpose?You could do that under the acquirement, that the bug in Debian Jessie's guest additions for mounting shared folders has been fixed in meanwhile. I don't know the current status.
Why don’t you just mount the Whonix 7 vdi directly as a second drive in the Whonix 8 workstation. Don’t see why the extra step via a new drive does help in any way.
You’re right. One could (optionally) Backup their Whonix VM, detach it’s vmdk image and attach it in the new VM.
while it usually worked for me, moving the drive from one virtual machine to another has resulted in virtualbox giving me a rather cryptic error on a few occasions. the method i detailed, while involving a couple more steps, has yet to generate any errors for me. so, they seemed like safer instructions.
Loop mounting any untrusted or dodgy disk image on the host is dangerous, as the contents of the disk are in direct contact with the host memory. For example, a real situation is If there is any malformed thumbnail of a file you downloaded it could trigger an exploit in the host thumbnail rendered or file explorer and own your system.
You should NEVER mount it, but instead follow this section in the wiki Patrick pointed to : Transfer files from the Whonix Workstation into a different Whonix-Workstation through a VDI file
This acts as a virtual usb of sorts.
Maybe I don’t understand the problem, but what about using a fully encrypted cloud storage to transfer files between VMs? I’m not thinking about Google or Microsoft but rather Mega. Files get encrypted/decrypted in your browser so it should be pretty safe, unless your VM is compromised and then it won’t matter anyway.
This time the javascript may be legit. Next time the javascript may store a copy of the key and send it elsewhere. In-browser encryption can only be secure, if either the browser itself or an add-on encrypts it. Until browser encryption add-ons get available and mature, you’re much better off using better vetted encryption methods, such as luks or gpg.