Whonix-LXQt-18.0.8.7
I enable Shared Clipboard & Drag-and-Drop features inside VirtualBox , but it doesn’t work .
In previous versions all worked from the box , but in 18.0.8.7, by default , these features are disabled .
Clipboard sharing in VirtualBox is unfortunately broken in Whonix 18. See:
Drag-n-Drop hasn’t been known to work historically. If it did work previously, it’s probably also broken by the switch to Wayland.
Shared folders can be used as an alternative for both features. This does work in Whonix 18 and is likely not as breakage-prone as clipboard sharing and drag-n-drop. See:
Note: Whonix is based on Kicksecure.
1 Like
Thanks for the answer .
Not good news for me .
Shared Clipboard is critical for me and cannot be replaced by Shared Folder in any way.
I was hoping that it would be possible to configure Shared Clipboard in Whonix 18 .
In this case I will continue to use Whonix 17 .
When can this be fixed ?
The fix would have to land in VirtualBox. Oracle is planning on fixing it but has given no ETA.
If you have programming knowledge, the best way forward would be to contribute a fix to VirtualBox upstream.
Shared folders can be used as an alternative for a shared clipboard by doing the following:
- Host to guest copy
- On the host, make a text file in the shared folder, paste the text into it, then save the file
- In the guest, open the text file, select all, and copy
- Guest to host copy
- Same steps as above, but reverse the host and the guest
Alternatively, you could also switch to using Qubes-Whonix on Qubes OS R4.3. The Qubes global clipboard is still functional in Whonix 18.
2 Likes
I’ll wait for Oracle to fix Shared Clipboard. Unfortunately, now there is no time to deal with Qubes.
Shared Folder does not suit me at all. I have sensitive data and it cannot be copied to an unencrypted text file.
Is Shared Folder safe to use when Workstation is connected to the Internet? I thought that Workstation should be offline when the Shared Folder is mounted.
Why is the clipboard “secure enough” but a text file isn’t? In both instances, any application on either the workstation or the host will be able to read the data, provided that application is running under the proper user account. The clipboard is likely just as accessible (maybe even more accessible) than files on the disk. (One critical difference though is that files on the disk will persist and may be hard to permanently erase. In that instance though you could store the shared folder in a tmpfs or ramfs on the host, keeping the data in memory similar to the clipboard.)
That depends on your threat model, but in general, yes, it should be safe. If the workstation is compromised, malware will be able to read from and likely write to the shared folder, but that could happen even if you disconnect from the Internet first. Malware shouldn’t be able to access files on the host outside of the shared folder.
2 Likes
I have password manager file on the host and if it will be stolen and sent somewhere attacker should have a password to open it , in case with text file all data unencrypted and easy accessible .
this too was a problem for me
thanks I’ll read how to do this
I didn’t know this it’s a very useful information , that malware can only access files inside shared folder and other files on host should be in safe.
really appreciate for your time and your answers !
1 Like
If you go this route, I’d recommend disabling swap on the host (or putting it on an encrypted swap partition). Otherwise a tmpfs may swap your password data to the disk anyway. ramfs shouldn’t be vulnerable to that (it keeps everything in the disk cache where it can’t be swapped out, as I understand it), but it’s also easy for the guest to DoS your host by writing a huge file into the shared folder in that instance.
2 Likes
Done
yes , other sources say the same
thanks for fast support !
1 Like
It was promised (on VB github) to fix this a long time ago but no work on this bug is noticeable. It is quite possible that it will not work at all. A broken function of clipboard sharing makes working on Whonix 18 (VB) extremely difficult and unrealistic.
1 Like
Partial duplicate of:
Whonix 18 - Wayland based - VirtualBox - Clipboard Sharing - Broken
I completely agree
I tried the options suggested @arraybolt3
But that’s not it at all
Can’t use password manager for all VMs
I decided to stay on Whonix 17 for now, saving the install file like gold
Where can I download previous versions of Whonix ? Is there an archive ?
I made a (temporary) fix to this issue:
http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/i-made-a-fix-for-the-shared-clipboard-issue/22705
1 Like
TNX
I answered in your thread
Hello,
I am new to Whonix-Virtualbox 18 from Whonix-Virtualbox 17, and I am trying to learn the new system.
I see in the documentation here (http://www.w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion/wiki/VirtualBox/Guest_Additions#Clipboard_Sharing) that clipboard sharing is not working. The documentation suggests only one solution. That solution is to use a shared folder to copy and paste things from the host and guest. But not everyone might want to do this, since it weakens the isolation of the virtual machines.
Would it be reasonable to use a chat application installed on both the host and guest system instead? For example, Onionshare could be used (http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/OnionShare).
Is there any reason why the documentation prefers to suggest using a shared folder? I am having a look over the “anonymity modes” concept in the documentation (http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Tips_on_Remaining_Anonymous#Keep_Anonymity_Modes_separate), but I do not see an anonymity mode for talking to yourself in order to share clipboard data.
1 Like
Onion services add more attack surface. Generally. For details, see: Onion Services - Whonix
I completely agree with this
For me, a non-working shared clipboard on Whonix 18 is a serious disaster
I understand that no one will cancel the transition to Wayland
It’s a shame that this has hit users using Whonix with VirtualBox so hard
I hope that this will be fixed in VirtualBox because on github VirtualBox they wrote that “KDE Plasma is going to drop X11 session in Plasma 6.8”
( Clipboard sharing with wayland guest not working · Issue #33 · VirtualBox/virtualbox · GitHub )
which means Shared Clipboard will not work either
I hope for a miracle , the solutions proposed on the forum do not work for me because they all weaken security
I will be keeping a close eye on new versions of Whonix and checking out the Shared Clipboard right away
I’m not sure I understand this argument. There has to be some communication between the VM and the host for the VM to start, display pixels on the screen, write to the disk, talk to the network, etc. Folder sharing may look like it’s reducing isolation by sharing host resources with the guest, but in reality it’s not much different than all of the rest of the features the virtualizer exposes to the guest. Unless you expect the virtualizer has a vulnerability that will allow the guest to read or write files outside of the shared folder, it’s reasonable to assume that the virtualizer will properly confine file I/O to the shared folder. If you don’t share a folder that contains sensitive info, there shouldn’t be a problem.
Any mechanism that you would usually use to move files or text from one computer to another can be used to move files or text from the VM to the host and vice versa. Chat, email, cloud storage, pastebins, file sharing services, FTP, SSH, NFS, local HTTP servers, USB flash drives (if used with USB passthrough), etc. come to mind. The attack surface presented by each one varies, which one is most suitable for you will depend on your threat model. Note that whatever “middleman” you expose the file to will be able to read whatever you paste, so avoid using untrusted services.
(I’ve sometimes used netcat to copy a file from one machine to another, it works quite well. If you use port forwarding in VirtualBox, you can do something like nc -l 192.168.0.1 7897 < file.txt in the guest, then nc 127.0.0.1 7897 > file.txt on the host, wait a few seconds, then terminate both nc instances. If you aren’t sure if the copy is done or not, you can check if the file size on the destination machine is still growing using du -b. There’s probably a way to make this more efficient, for instance by making the nc commands terminate automatically when the file is done transferring.)
I’m not sure I understand this argument. There has to be some communication between the VM and the host for the VM to start, display pixels on the screen, write to the disk, talk to the network, etc. Folder sharing may look like it’s reducing isolation by sharing host resources with the guest, but in reality it’s not much different than all of the rest of the features the virtualizer exposes to the guest.
An argument might go something like this.
Scenario 1- I am using a shared folder for clipboard support. A virus infects the whonix-workstation-virtualbox. It spreads to the shared folder. Now that it is on the shared folder, it is able to infect the host system. Even if I am using live mode in whonix-workstation-virtualbox, the virus is able to persist on my host system.
Scenario 2- I am running some sort of messenger on both the host system and the guest system. The messenger is set up to only share text between the host and the guest system. A virus infects the whonix-workstation-virtualbox. It is unable to spread to the host system because the messenger cannot share files, only text. If I am using live mode in whonix-workstation-virtualbox, the virus is wiped upon shutdown of whonix-workstation-virtualbox.
Unless you expect the virtualizer has a vulnerability that will allow the guest to read or write files outside of the shared folder
Ideally, I would want to have mitigations agaisnt zero-day vulnerabilites if possible. But to be honest, I do not know what security experts think about the security of virtualbox nowadays. Still, I would guess that Whonix-Virtualbox is the most common configuration of Whonix. It is officially supported, unlike QEMU/KVM. And it is more accessible than Qubes-Whonix. If an attacker were to try to target Whonix specifically, they might prioritize attacking Whonix-Virtualbox for this reason.
I understand that no one will cancel the transition to Wayland
It’s a shame that this has hit users using Whonix with VirtualBox so hard
Maybe you could consider installing the xfce environment and use x11 with that instead? The clipboard might work in that case. But I assume such a scenario is now unsupported for Whonix 18.