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
Really required to recompile? It works but… You could also just:
sudo systemctl stop kloak.service
sudo kloak -v
But that wouldn’t be an exact reproduction because it doesn’t run under systemd and does not have seccomp enforcement.
Instructions for enabling debug mode and log sharing have been created just now:
Keystroke Deanonymization - Whonix chapter Kloak Debug Mode in Whonix wiki
That’s a good point. I’ll edit my earlier comment to make those changes. In the instructions between steps 4 and 5, I think a sudo systemctl daemon-reload is needed to apply the changes to the unit file. I made an update to that instruction page to include it.
1 Like
Indeed. Thank you. Instructions are now fixed in the wiki.
This is now in the testers repository.