Kicksecure inside Debian Template sdwdate qrexec Denied message

[adrelanos]

Installing Kicksecure inside Debian Template (Following distro-morphing instructions) the Appvm which is based on kicksecure template will give tons of the same error reported above: (The Appvm called I2P)

Any operation using the terminal/command line like e.g remove or install something it will regenerate similar messages.

(This can be reproduced in StandaloneVM based on Debian then changed to Kicksecure)

Originally posted by @Nurmagoz here: #7013 (comment)

[adrelanos]

Status of Kicksecure inside Qubes:
https://www.kicksecure.com/wiki/Qubes#Template

Related Qubes qrexec source code file:
https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/master/qubes-rpc-policy/80-whonix.policy

qrexec policy line which is causing this:

whonix.NewStatus     *         @anyvm            @anyvm            deny

Kicksecure uses sdwdate:
https://www.kicksecure.com/wiki/Sdwdate

qrexec polcy line which is preventing this for Qubes-Whonix:

whonix.NewStatus     *         @tag:anon-vm      @tag:anon-gateway allow  autostart=no

It's prevented in Qubes-Whonix becuase these VMs have qrexec tag anon-vm added by https://github.com/QubesOS/qubes-core-admin-addon-whonix.

How should Kicksecure-Qubes sdwdate support be fixed in Qubes dom0 qrexec policy?

In absence of a Kicksecure-Qubes template and Qubes dom0 package qubes-core-admin-addon-kicksecure that seems difficult.

For sure we shouldn't re-use the tag anon-vm.

Telling users to manually add any tags seems cumbersome.

Changing the default deny to allow I guess also wouldn't be acceptable?

Should Qubes dom0 package qubes-core-admin-addon-kicksecure be invented? As long as there's no KIcksecure-Qubes template maintainer that I guess wouldn't work anyhow.

For tracking purposes:
This has just been fully diagnosed but directions from Qubes are required on how it could be fixed.

[DemiMarie]

Why is a non-Whonix VM calling whonix.NewStatus to begin with?

[adrelanos]

This is primarily a Qubes dom0 issue.

Suggested ticket tags:

• C: Kicksecure - New tag? If Qubes is interested in that.
• P: default
• T: bug

Why is a non-Whonix VM calling whonix.NewStatus to begin with?

Kicksecure uses sdwdate.

[DemiMarie]

Why is a non-Whonix VM calling whonix.NewStatus to begin with?

Kicksecure uses sdwdate.

Is renaming the service an option? whonix.NewStatus (a) implies that the service is Whonix-specific and (b) provides no indication that sdwdate is involved. As far as tags, I would be fine with using sdwdate-client or similar.

[adrelanos]

Why is a non-Whonix VM calling whonix.NewStatus to begin with?

Kicksecure uses sdwdate.

Is renaming the service an option?

Yes, sure.

However, that file is still part of Qubes dom0 package qubes-core-admin-addon-whonix which still would't be 100% clean but might be acceptable?

Even if renamed, I still don't see how we can fix the issue reported here without changing the sdwdate qrexed default from deny to allow or without a Kicksecure-Qubes template maintainer.

[marmarek]

Lets first try to figure out what should be the final goal, and only then - how.

Installing Kicksecure inside Debian Template (Following distro-morphing instructions) the Appvm which is based on kicksecure template will give tons of the same error reported above: (The Appvm called I2P)

Ok, so the user did just this: took Debian template and morphed it into Kicksecure. No Whonix is involved or even installed. What should happen?

[adrelanos]

Kicksecure VMs are primarily used non-torified, i.e. over clearnet (or VPN). That's the main use case. Some users might torify them for some reason but that would be the corner case. Torified Kicksecure makes little sense - because in that case using Whonix would be better.

Lets first try to figure out what should be the final goal, and only then - how.

Installing Kicksecure inside Debian Template (Following distro-morphing instructions) the Appvm which is based on kicksecure template will give tons of the same error reported above: (The Appvm called I2P)

Ok, so the user did just this: took Debian template and morphed it into Kicksecure. No Whonix is involved or even installed. What should happen?

Good question. I guess...

The Kicksecure VM should be allowed to qrexec send whonix.NewStatus (to be renamed in a generic way) to sdwdate-gui running inside @tag:anon-gateway.

It's non-ideal since the Tor inside @tag:anon-gateway (most likely sys-whonix) doesn't really handle the Tor connections used by sdwdate. @tag:anon-gateway is just "coincidentally" the only place where sdwdate-gui is running inside Qubes as we don't know/have any more appropriate / more centralized place for it.

For Kicksecure outside of Qubes none of this is an issue. It has its own desktop environment so using its own sdwdate-gui is appropriate. How to best implement this in Qubes is a good question.

Then also the @tag:anon-gateway should be allowed to send whonix.SdwdateStatus and whonix.GatewayCommand (both to be renamed in a generic way) to the Kicksecure VM.

That is until a cleaner solution https://forums.whonix.org/t/whonix-sdwdatestatus-service-starts-vms-that-were-killed/18510 is implemented which would abolish the need for a two-way qrexec calls.

[marmarek]

What's the purpose of this service? Is it only reporting status to be displayed in a single place (instead of separate icon for each qube)? Or is it also assisting with the actual time synchronization? If the former, maybe the solution for the case without Whonix is to run sdwdate-gui locally in the Kicksecure VM? May not be optimal if there are many of them, though...

[adrelanos]

What's the purpose of this service? Is it only reporting status to be displayed in a single place (instead of separate icon for each qube)?

Yes, "mostly" only reporting the status and [...]

Or is it also assisting with the actual time synchronization?

[...] "Not directly." Except for usability. It offers a few handy buttons buttons

• Show sdwdate status
• Open sdwdate's log
• Restart sdwdate
• Stop sdwdate

sdwdate-gui homepage:
https://www.kicksecure.com/wiki/Sdwdate-gui

screenshot of that menu:
https://www.kicksecure.com/wiki/File:Sdwdate2.png

If the former, maybe the solution for the case without Whonix is to run sdwdate-gui locally in the Kicksecure VM?

Yes, that would of course work.

May not be optimal if there are many of them, though...

Indeed. It's non-ideal.