Actually scratch that. I don’t think there is much difference to justify enabling this stuff. I’ll disable it once the commit goes thru. No point of having clipboard either.
Looks like you did the todo already.
The https://github.com/Whonix/shared-folder-help package currently does not do much. (See https://github.com/Whonix/shared-folder-help/blob/master/debian/shared-folder-help.postinst#L28 - it’s just 4 commands.)
Automounting requires a bit research and testing. Please see https://github.com/Whonix/Whonix/issues/223 if you would like to take the testing part.
It still needs spice-vdagent to be activated when vdagent is installed in Whonix. Maybe you will enable it be default?If possible, yes. What is to be done? sudo apt-get install --no-install-recommends spice-vdagent That's all? It's small enough. Can be installed by default. And it does nothing if "/dev/virtio-ports/com.redhat.spice.0" is not detected. So no reason not to install it.
Maybe “sudo service spice-vdagent status” can be used to check if it’s enabled? Fails for me in VirtualBox as expected, but should work work for you in KVM.
Automounting requires a bit research and testing. Please see https://github.com/Whonix/Whonix/issues/223 if you would like to take the testing part.
I will test it and report back.
If possible, yes. What is to be done? sudo apt-get install --no-install-recommends spice-vdagent That's all? It's small enough. Can be installed by default. And it does nothing if "/dev/virtio-ports/com.redhat.spice.0" is not detected. So no reason not to install it.
Yes thats all what t takes.
My question is should I leave clipboard sharing on by default? What harm could be done in your opinion?
Maybe "sudo service spice-vdagent status" can be used to check if it's enabled?
Yes.
Cleaning the wiki now.
Can you please take a quick look at the readme and see if the commands for moving images into /var/lib/libvirt are correct?
utomounting requires a bit research and testing. Please see https://github.com/Whonix/Whonix/issues/223 if you would like to take the testing part.
Doesn’t work
Did testing with spice again and everything is fine. Please include it. Sorry for the conflicting reports.
EDIT:
Turns out that some times the virt-viewer window would stop updating the visual status of the guest. By closing and reopening the window everything would continue as normal again. The guest wasn’t frozen its just the graphical output from it would stall sometimes. Thats not a problem and so we should go ahead and include it.
[quote=“HulaHoop, post:205, topic:166”][quote]utomounting requires a bit research and testing. Please see https://github.com/Whonix/Whonix/issues/223 if you would like to take the testing part.
[/quote]
Doesn’t work[/quote]
Updated https://github.com/Whonix/Whonix/issues/223. Please try again. Works for VBox. Hopefully for KVM as well. Really adding both! Because that’s what I might implement in the shared-folder-help package. [Patching /etc/fstab would be a bit unclean and weird, but there is no other way to implement this.]
Fixed a few things in the readme.
Why do you suggest running virsh as root (using su beforehand)? Not really required?
Why does it include
“sudo mv /$PATH/Whonix-Gateway/Whonix-Gateway.qcow2 /var/lib/libvirt/images”
when you’re already suggesting
“cp --sparse=always /$CURRENT-PATH/Whonix-Gateway.qcow2 /$NEW-PATH/Whonix-Gateway.qcow2”
?
It lacks the comments, we’re using for VBox readme already:
https://github.com/Whonix/Whonix/blob/master/build-steps.d/2700_export-vbox-vm#L25
Why put so much into the readme anyway? Who reads readme anyway? Why not put most of the stuff into the wiki, where it is searchable by search engines and better visible?
Added spice-vdagent by default on Whonix 9.
Clipboard sharing should be better disabled by default. It already is for VirtualBox. Otherwise when you copy something private in a VM, such an URL and later accidentally paste it in a clearnet host browser, this could deanonmize yourself. [Due to search engine and url auto suggest, as soon as you pasted something into the url or search bar in browser, it already gets transmitted to third parties.] That’s bad for usability, but a bullet we should better bite for better security.
Why do you suggest running virsh as root (using su beforehand)? Not really required?
You see what is fit here, I just wrote what I do sometimes
Why does it include "sudo mv /$PATH/Whonix-Gateway/Whonix-Gateway.qcow2 /var/lib/libvirt/images" when you're already suggesting "cp --sparse=always /$CURRENT-PATH/Whonix-Gateway.qcow2 /$NEW-PATH/Whonix-Gateway.qcow2" ?
Just in case they don’t have enough space for a copy and want to move it instead.
It lacks the comments, we're using for VBox readme already: https://github.com/Whonix/Whonix/blob/master/build-steps.d/2700_export-vbox-vm#L25Why put so much into the readme anyway? Who reads readme anyway? Why not put most of the stuff into the wiki, where it is searchable by search engines and better visible?
Not everyone will want to read an entire wiki for something they download. However with the file included, they will soon turn to it if they have no idea what to do with the image they got.
If you want to duplicate the readme onto the wiki as well then go for it. But not including a readme with the KVM version would be a big mistake IMO
Tried with the edited fstab and its not working
Ok, but do you think that spice is bad for security? Is there a tradeoff? What does TAILS do?
https://labs.riseup.net/code/issues/5730
They do enable them for virtualbox and kvm. But clipboard is disabled like we decided to do. They debated whether this could expose the guest resolution to an attacker but decided its not a problem as the browser hides this fact.
I was using the wrong label: share instead of shared. But this works:
Maybe we can addshared /mnt/shared 9p trans=virtio,version=9p2000.L,rw 0 0
shared /mnt/shared vboxsf uid=1000,gid=1000 0 0to /etc/fstab?
Tried again with the correct label the fstab.d solution and it doesn’t work, probably because of the reasons you cited. Consider this a case closed.
Another argument for the readme to include what it does: Imagine I am an activist, who is not technically knowledgeable, living in a country with a firewall that blocks access to Tor and Whonix websites. The only way I got the image was with someone distributing it clandestinely. How would I be able to get the kvm version up and running? Virtualbox is simple enough but not kvm - at the moment at least, I really hope they design a simple way to do this.
This is just an example.
First of all, I need to understand the question better. Why is getting VirtualBox simpler than kvm? Both requires downloading big files from mirror.whonix.de?
Let’s use “shared”, then we can share it with VBox, because VBox doesn’t work with “share”.
[quote] [b]But this works:[/b] [/quote] Maybe we can addshared /mnt/shared 9p trans=virtio,version=9p2000.L,rw 0 0
shared /mnt/shared vboxsf uid=1000,gid=1000 0 0to /etc/fstab?
Good. Now this needs to be implemented in the maintainer scripts to add/remove it on install/uninstall from /etc/fstab. No idea when I get to it but we got ticket and it’s a good improvement.
[quote=“HulaHoop, post:212, topic:166”]https://labs.riseup.net/code/issues/5730
They do enable them for virtualbox and kvm. But clipboard is disabled like we decided to do. They debated whether this could expose the guest resolution to an attacker but decided its not a problem as the browser hides this fact.[/quote]
They didn’t debate spice. Quote: “(Note that these concerns are shared with the Spice/QXL virtualization environment, as we’re running spice-vdagent. No idea what the defaults are there. Off-topic, would need a dedicated ticket if we care.)”
You could get a Tails centric perspective (mindset: i don’t know about Whonix, got a Tails question mindset); quote them on that; and make a new ticket for that. Wouldn’t hurt reading their perspective.
Its not about one being easier to get than the other, but setting it up is easier, and so instead of forcing someone to visit whonix.org for instructions, we give it to them offline.
On KVM readiness for Whonix 9:
IMO KVM support is in great shape for next stable release. The blocker of xml validation is not a showstopper since using older version of libvirt means some features are not recognized yet by the older software version you have. last time I checked all files validate fine here.
Update on import/export Support:
Gnome Boxes, another simplified GUI for libvirt will have an OVF import feature added. Note that OVF is not the vmware vmdk specfic format OVA. In this sense making it a true standard.
Its in the works and the Gnome contributor behind it has posted that he plans to make it into a stand-alone library so it could be used by other projects. Meaning it could be easily included in virt-manager too.
His post:
Initial commit:
https://gitorious.org/govf
Quite some KVM related work has been done today.
Moved “xml does not validate” to answered questions and disabled xml validation in Whonix’s build script.
I find
really confusing. Users tend to mindlessly copy and paste commands. No offense, since in the flood of information, sometimes happens to me as well. Just want to adjust the documentation we have to the users we have and not to the users we wish we had. I strongly believe in “anything can go wrong, will go wrong” - talking from experience with previous Whonix support. And every support request, eats up development time. So I wish KVM to cause as little support requests as possible.
Therefore I think it is best if we recommend to use an arbitrarily chosen default folder to store Whonix images. Such as the user’s home folder ~/. Then users who did that can mindlessly copy and paste the commands and will not create support requests due to wrong paths.
And to suit the more experienced users as well, we can just add a footnote such as “These are example paths so less experienced or less attentive users can mindlessly copy and paste these commands. If you are an advanced user, feel free to download Whonix to a custom location.” I guess this is best to make both groups of users happy.
More soon.