Running corridor on sys-net?

[swisspal441]

I followed the instructions in the Whonix docs for corridor
and I setup corridor on the sys-net VM instead of a seperate sys-corridor VM.

It works just fine but I am wondering whether this is actually “safe” in comparison to running it as sys-corridor?

Sys-net should be treated as an unsafe VM but the reason why I run it on sys-net is that I want to have a fail-safe mechanism in case I accidently choose sys-firewall or sys-net as NetVM. I want everything on my system to be tunneled through tor. Always.

Are there settings on sys-net that could interfere with the corridor service that are not on a seperate sys-corridor VM? I am using debian 10 as template for sys-net. I disabled IPv6, installed wifi drivers and setup corridor. That’s it.

And last question: Can I install onion-grater on the sys-net VM to filter the GETINFO address command? Are there other possibilities for malware to get the clearnet IP if the system is connected to sys-net with corridor running?

[Patrick]

I didn’t research that. Wasn’t considered during development. Therefore unsupported.

Unsupported

You could try asking upstream or Qubes support.

Help, Support, and Mailing Lists

Are there other possibilities for malware to get the clearnet IP if the system is connected to sys-net with corridor running?

Yes. Malware could set up a Tor relay and connect to it.

Can I install onion-grater on the sys-net VM to filter the GETINFO address command?

In theory, yes. But unsupported.

Likely not needed. Tor control protocol access could be limited to localhost only. Tor might be using Tor unix domain socket files by default nowadays. Check your open ports. No open port reachable from other VMs, then no control protocol filtering (onion-grater) required.

Any other (real or malware internal) Tor process in any other VM that isn’t protected by onion-grater (Whonix-Gateway) could still be using GETINFO address.

[swisspal441]

Ok, thank you.

In theory, yes. But unsupported.

Likely not needed. Tor control protocol access could be limited to localhost only. Tor might be using Tor unix domain socket files by default nowadays. Check your open ports. No open port reachable from other VMs, then no control protocol filtering (onion-grater) required.

Any other (real or malware internal) Tor process in any other VM that isn’t protected by onion-grater (Whonix-Gateway) could still be using GETINFO address.

Can you maybe explain me how to do so?

I mean, I can of course see open ports with netstat -pln on sys-net. But how do I make sure that no outside AppVM can connect to them?

In the default qubes configuration it shouldn’t be possible, right?

Edit:
I connected a fresh VM directly to sys-net and ran “telnet ip port” with the ip of sys-net and the tor control port.

Response was: telnet: Unable to connect to remote host: No route to host

Is there anything else I can do to make sure that there is not connection possible to the port?

Any other (real or malware internal) Tor process in any other VM that isn’t protected by onion-grater (Whonix-Gateway) could still be using GETINFO address.

And just double checking: By that you mean that even if the control port on sys-net (in this case) is not accessible by a directly connected AppVMs then it wouldn’t matter because the AppVM could’ve run the command on its own tor process/control port (if it created one)?

Sorry, it’s a bit difficult for me to understand all of this. But I am trying

[Patrick_mobile]

And just double checking: By that you mean that even if the control port on sys-net (in this case) is not accessible by a directly connected AppVMs then it wouldn’t matter because the AppVM could’ve run the command on its own tor process/control port (if it created one)?

Yes.

[swisspal441]

Ok, I understand. So using corridor for this purpose doesn’t really make sense.

I feel stupid now. I just realised that there’s probably a solution that’s much easier to achieve what I want.

I can just drop incoming packets on sys-net that are not coming from sys-firewall. And then do the same thing on sys-firewall for sys-whonix.

But I’m not sure if I can just flush the old input chain and if this configuration would interfere with anything else on qubes.

I guess that is not whonix related though. Therefore I will send a message to the qubes users mailing list.

Thanks for answering my questions