Yeah there is a lot of other stuff I added in there after the qubes support was done. There were some other features I figured might be nice to have in kloak as well and since it was taking a little while to either be approved or denied, I figured I would get it in in that pull request as well instead of a different pull request for each one. It may be better to move the other changes to another one though. That was my first pull request I’ve ever submitted, so I wasn’t sure what the best practice was.
I am not sure either. Just trying to guess from other projects.
I almost have this ready to make a pull request, but in the templates, there will need to be a few changes to use it.
- user will need to be added to the input group
- the environment variable CREATEINPUTDEVICE will be need to be set to 1 before the gui-agent loads
The first change is needed because xinit is running as user and when the input device is created by the qubes gui-agent, the device has a user owner of root and group owner of input, so xinit won’t be able to use the device without the group add.
The second change is needed to make it opt-in so input devices are only created if it’s specifically requested.
I should be able to make a pull request by the end of the day Sunday.
1 Like
This is a development forum thread. It’s in the Development sub forum. Please do not use this for user support questions.
Nice!
Don’t know about this. This needs to be discussed with Qubes.
Also don’t know if or how Qubes implementation of sys-gui (GUI domain) will interact with this.
This one too.
If needed, then Whonix-Workstation could ship a systemd drop-in file for Qubes gui-agent which sets this environment variable. An alternative mechanism could be a status file.
Otherwise environment variables could get messy. (How to set global environment variables as a Linux distribution? - /etc/environment.d)
But let’s see. These details can be discussed later after getting feedback from Qubes.
That’s really good to know, that section checking for the environment variable was only a few lines, so it’s easy to change. I tested checking to see if the /etc/whonix_version file exists and creating it by default in whonix and that works as well.
Is the /etc/whonix_version file likely to always be there across versions? Based on the contents it looks like it, but wanted to make sure. If not, what would be the easiest method for you to implement within the whonix template to indicate that an input device should be created? I’ll design the opt-in around that.
If checking for the existence of /etc/whonix_version is likely to always work between versions, I’ll figure out another opt-in method for other qubes and just always have it create the device for whonix.
1 Like
Why not always unconditionally create the device? Security? Threat model?
1 Like
marmarek had mentioned in a thread a while ago that it should be limited to Whonix VMs and they may package it as an optional dom0 package. I wasn’t sure if that was specifically referring to kloak, or the input device creation as well. The easier option would be to always have it created and if qubes is open to that, I can have it do that.
1 Like
That was about adding randomized delay for keystrokes on the host. Not about exposing /dev/input.
Dunno I would just keep it simple and ask.
1 Like
To reliably detect Whonix:
Whonix ™ friendly applications best practices chapter Programmatically Detecting Whonix ™ in Whonix wiki
But best avoided if upstream (Qubes) doesn’t request this.
Also I guess it should be a neutrally named Qubes status file. Maybe a Qubes service | Qubes OS file. But that’s also only something that upstream can answer.
This is now in the testers repository.
Mentioned the tests here:
Keystroke Deanonymization - Whonix chapter Defense Testing in Whonix wiki
but this is yet to be tested and documented. Help welcome.
Is this when using the code from my fork, vmonaco’s current dev branch, or vmonaco’s current master branch? The code from my fork with the mouse movement obfuscation hasn’t been merged yet. I just want to make sure I’m troubleshooting the right one.
Also, is this just when tapping on the touchpad to sent a left click or right click, or is this also when doing a double tap, hold, and drag to move a window around?
2 Likes
Partially answered here just now: touchpad's tap to click gestures no longer work · Issue #54 · vmonaco/kloak · GitHub
Thanks for your reply. Both are broken. Basically any tap emulation is non responsive.
Page scrolling gestures work however.
1 Like
In the GitHub - Whonix/kloak master branch, the only commit that modified main.c was The rescue_len variable was not initialized, causing undefined behavi… · Whonix/kloak@54f0b3e · GitHub and the changes to main_loop() where the events are processed are very minimal. I haven’t been able to replicate it on my laptop yet. Would you mind trying the following please?
- Stopping the kloak service and rebooting
sudo systemctl disable --now kloak.service
sudo reboot
After the reboot, would you mind seeing if the issue persists? This is just to confirm it is definitely kloak.
If the issues persist, would you mind completing the instructions in the link below to enable debug mode, try to replicate the issue a few seconds after kloak starts, end kloak with the rescue keys (leftshift + rightshift + escape), then send me a copy of the journalctl output?
After restarting kloak and trying to replicate the issue, you can view journalctl logs for only that run of kloak using:
sudo journalctl _SYSTEMD_INVOCATION_ID=$(systemctl show -p InvocationID --value kloak.service)
After that you can re-enable kloak with:
sudo systemctl enable --now kloak.service
2 Likes