Current State of Kloak?

Patrick · November 16, 2024, 8:39pm

A slightly more sophisticated Makefile

Whonix:master ← Fat-Zer:better-makefile

opened 07:41PM - 15 Nov 24 UTC

- support for override of the compiler and utils - support for append/override …CFLAGS - a target to update man pages - install target - better handling of conditional flags, particularly: - disable some warnings on non-gcc compilers - handle GNU's tuples like `x86-64-pc-linux-gnu` and `aarch-unknowv-linux-gnu` - organize CFLAGS by sorting them into categories This pull request changes... ## Changes ## Mandatory Checklist - [X] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.whonix.org/wiki/Terms_of_Service), [Privacy Policy](https://www.whonix.org/wiki/Privacy_Policy), [Cookie Policy](https://www.whonix.org/wiki/Cookie_Policy), [E-Sign Consent](https://www.whonix.org/wiki/E-Sign_Consent), [DMCA](https://www.whonix.org/wiki/DMCA), [Imprint](https://www.whonix.org/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [X] I have tested it locally - [ ] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it Fixes #

Mycobee · November 17, 2024, 4:50pm

@Patrick is this code stable and maintainable as it currently exists?

i.e. do we see us having the resources to maintain it for the longhaul?

Patrick · November 18, 2024, 11:07am

Yes.

Patrick · November 18, 2024, 12:25pm

Patrick · November 19, 2024, 7:06pm

Signing releases · Issue #7 · Whonix/kloak · GitHub

Patrick · February 14, 2025, 2:24pm

In context of kloak-alike functionality inside Qubes:

github.com/QubesOS/qubes-issues

Very weird behavior when trying to call `qvm-features-request` with values that contain spaces

opened 03:59AM - 14 Feb 25 UTC

ArrayBolt3

P: default

### Qubes OS release Qubes OS 4.3 ### Brief summary `qvm-features-request` an…d `qubes-core-admin` exhibits very strange failure patterns if you call `qvm-features-request` from inside a template and try to set a key-value pair with a value that contains a space. In essence: * Setting a key-value pair to a value without a space works. * Setting a key-value pair to a value that contains a space fails. * If you try to set a key-value pair to a value that contains a space, subsequent attempts to set a key-value pair to a value without a space *may fail*. So far the behavior pattern seems to be reproducible, but somewhat unpredictable. ### Steps to reproduce 1. In dom0, kill the qubesd service with `sudo systemctl stop qubesd`. 2. In dom0, launch qubesd in a terminal with `sudo /usr/bin/qubesd -vv` for debugging. 3. Launch a template VM, it doesn't matter which one. I'm using `fedora-41-xfce`, but `debian-12-xfce` also works. 4. Run the following set of eight `qvm-features-request` commands, one at a time: Call 1: Run `qvm-features-request abc=def --commit`. Call 2: Run `qvm-features-request abc.def=def --commit`. Call 3: Run `qvm-features-request abc="def ghi" --commit`. Call 4: Run `qvm-features-request abc.def=def --commit`. Call 5: Run `qvm-features-request abc=def --commit`. Call 6: Run `qvm-features-request abc.def=def --commit`. Call 7: Run `qvm-features-request abc.def="def ghi" --commit`. Call 8: Run `qvm-features-request abc.def=def --commit`. ### Expected behavior All `qvm-features-request` calls should exit non-zero, regardless of whether they contain spaces or not. The calls should ultimately be no-ops since dom0 has no code to actually set the requested features. ### Actual behavior The following pattern is exhibited, with anomalies bolded: Call 1: Succeeds. Call 2: Succeeds. Call 3: Fails. Call 4: **Fails** (even though the value doesn't contain a space). Call 5: Succeeds. Call 6: **Succeeds** (apparently the previous success somehow got this case un-stuck?) Call 7: Fails. Call 8: **Succeeds** (maybe because we're dealing with the same key in both calls 7 and 8?) ### Additional information Every time a successful call is made, `qubesd` outputs a log message similar to `qubes.utils: Renamed file: '/var/lib/qubes/qubes.xml~XXXXXXX' -> '/var/lib/qubes/qubes.xml'` (where `XXXXXXX` are what appear to be random characters). Every time a failed call is made, `qubesd` outputs a log message like `app: permission denied for call b'qubes.FeaturesRequest'+b'' (b'fedora-41-xfce' -> b'dom0') with payload of 0 bytes`.

Patrick · February 14, 2025, 4:31pm

kloak-alike functionality might become available and enabled by default for Qubes-Whonix-Workstation users in Qubes R4.3.

Related ticket:

github.com/QubesOS/qubes-issues

Enable X11 event buffering in Whonix by default

opened 03:54AM - 13 Feb 25 UTC

ArrayBolt3

privacy C: Whonix P: default

### The problem you're addressing (if any) Now that https://github.com/QubesOS/…qubes-gui-daemon/pull/149 is merged, any VM in Qubes OS that supports a GUI daemon can have Kloak-like features (keyboard and mouse event delay) enabled on them. While most VMs probably would probably have their usability degraded if this feature was enabled on them by default, Whonix benefits greatly from having this feature because it directly helps it to accomplish its goal of providing additional anonymity to users. Right now a user has to explicitly set the `gui-ebuf-max-delay` feature to a non-zero value on a VM in order to enable event buffering. This is not something the average user should have to do, Whonix-Workstation should have this enabled by default. (Whonix-Gateway should potentially leave this disabled since the user won't be interacting with websites in Whonix-Gateway if used as designed.) ### The solution you'd like * Modify https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/main/qubeswhonix/__init__.py so that it responds to a feature request from a Whonix VM to set `gui-ebuf-max-delay`. Requests should only be honored if they fall between reasonable thresholds so that malware can't disable the delay entirely or set it to be so high as to render the VM unusable. * Add a script to Whonix's anon-ws-base-files package to request the feature and set it to a sensible value. This strategy will allow Whonix to adjust the delay in the future if it is desirable to do so. Alternatively, since the `gui-ebuf-max-delay` relies entirely on dom0 and doesn't require any domU-side code at all, we could just modify https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/main/qubeswhonix/__init__.py to set the feature all by itself one time, and that's it. This does mean that setting the delay is a "one shot" operation and if it turns out to be bad, another change to qubes-core-admin-addon-whonix will be needed. This would have the advantage of not allowing malware to even try to adjust the delay however. ### The value to a user and who that user might be Applications (especially websites) should have a harder time tracking the user via keyboard biometrics. (Mouse movements may also be obfuscated enough to make fingerprinting difficult through that method, though I'm not sure any concrete tests have been done on the mouse beyond "now it's laggy".) ### Completion criteria checklist _No response_

Patrick · March 24, 2025, 2:50pm

Related pull request:

github.com/QubesOS/qubes-core-admin-addon-whonix

Enable GUI event buffering for new Whonix-Workstation qubes

main ← ArrayBolt3:arraybolt3/event-buffering

opened 07:14PM - 23 Mar 25 UTC

ArrayBolt3

+3 -0

Pretty much as straightforward as it gets. Tested by installing in dom0 on Qubes… R4.3, then rebooting, then creating a new qube based on the whonix-workstation-17 template. `gui-events-max-delay` feature was set to `100` as expected and keyboard input into apps within the qube had noticeable jitter as desired. Fixes https://github.com/QubesOS/qubes-issues/issues/9771

Patrick · March 24, 2025, 2:51pm

Optional feature request:

unlikely
not crucial since this will be enabled by default in Qubes anyhow

github.com/QubesOS/qubes-issues

Allow end-users to customize GUI event buffering in Qube Manager

opened 07:21PM - 23 Mar 25 UTC

ArrayBolt3

C: manager/widget ux privacy P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… The problem you're addressing (if any) Event buffering is now a feature of the GUI daemon, which can be set by modifying the `gui-events-max-delay` feature for any qube that uses the GUI daemon. Currently this feature can only be used by advanced users who know where to find the documentation for the feature (a blurb in `/etc/qubes/guid.conf`, which isn't even used by the GUI daemon anymore) and who are willing to fiddle with the `qvm-features` command in a Dom0 terminal. Whonix-Workstation VMs will hopefully come with the feature set to a reasonable default value of 100 ms once https://github.com/QubesOS/qubes-core-admin-addon-whonix/pull/20 is merged, but just like kloak (the application that inspired the event buffering feature) is useful outside of Whonix, event buffering may be useful as well. Users need to be able to know the feature exists and how to configure it in order to use it. ### The solution you'd like We should provide some easy way to configure this setting, perhaps in Qube Manager. ### The value to a user and who that user might be Users can obfuscate keyboard rhythm biometrics from any VMs they want, regardless of OS, so long as they can interface with the GUI daemon. ### Completion criteria checklist (This section is for developer use only. Please do not modify it.)

(kloak is already default in non-Qubes for a long time.)

Patrick · March 25, 2025, 2:08pm

Patrick · April 6, 2025, 10:17am

Was merged.

The future of kloak-alike functionality in Qubes R4.3 and above is bright.

Patrick · April 19, 2025, 5:53pm

github.com/vmonaco/kloak

Status of Original kloak Repository and Whonix Fork

opened 05:51PM - 19 Apr 25 UTC

adrelanos

* time of writing: 20 April 2025 * [vmonaco/kloak](https://github.com/vmonaco/kl…oak) last git commit: Sep 25, 2023 * @vmonaco last comment in https://github.com/vmonaco/kloak/issues/10#issuecomment-2146658373: 4 June 2024 This GitHub repository can therefore probably be considered abandoned. @vmonaco's instrumental contributions have been highly valuable and appreciated. Let's hope he'll be back. We forked the repository and now maintain it under [https://github.com/Whonix/kloak Whonix/kloak].