Add Windows qvm-connect-tcp support.

[ernst-qos]

Summary:

• The purpose of this pull request is to add qvm-connect-tcp support for Windows VMs.
• Currently this implementation only covers outgoing connections. Depending on any and all feedback I can get on what I have so far I will add the functionality as well to connect into a Windows VM.
• Using qrexec-client-vm without a local program will instead tunnel STDIO to the remote similar to the behavior on Linux.
• TCP listening is implemented directly in qrexec-client-vm to avoid the need for a socat like tool on Windows.
• A batch script is provided with exactly the same behavior as its Linux counterpart.

TCP/Socat/Ncat:

On Linux socat is used for TCP <-> STDIO conversion, running socat on Windows requires a POSIX like environment, e.g., Cygwin.
To avoid the need for such an environment a tool native to Windows that could replace socat could be used. The only reasonable option for such a tool would be ncat. However, the ncat option has the following problems:

• The license.
• Their precompiled static binary is outdated and contains a critical functional bug that they resolved in 2013. Their precompiled binary is from 2010 and still has the bug.
• Antivirus software (notably Windows Defender) qualifies it as a hacker tool and quarantines it.
• Mingw builds of just ncat are "supported" but seems like an afterthought.

Instead of these options, I added about 200 lines of code to qrexec-client-vm to directly support tcp listening.

Open Questions:

• Where should the qvm-connect-tcp.bat script go, and how will it be made accessible to the user (unless it already exists, I would propose a new directory in Qubes Tools that can be added to the PATH).
• Is this custom TCP listening solution acceptable? If not, what would be the preferred alternative?
• If it is acceptable, shall I write a small tool to allow incoming connections and add it to qrexec-services? Or do we prefer to use ncat (or a similar program) for that?
• In the batch script we are jumping through quite some hoops to achieve similar behavior to the Linux version. Would it be preferable to change the semantics on Windows for the sake of simplifying the script? Or is the current solution, maybe with some tweaks from someone more experienced in batch script writing, acceptable?

ToDo:

• Add support for incoming TCP connections (now only outgoing is supported).
• Add Visual Studio build support (now only mingw builds work).
• Update the iso installer builder to include the new files.
• Add the qvm-connect-tcp.bat directory to the PATH for easy access.

[marmarek]

Thanks for the PR! Would you mind opening an issue and linking the PR to it, for better visibility?

@jevank do you have any thoughts on this?

[marmarek]

PipelineRefresh

[ernst-qos]

Thanks for the PR! Would you mind opening an issue and linking the PR to it, for better visibility?

Thank you for your quick response, I have opened an issue on the issue tracker, and when there is anything is else I can do, I'd be happy to.

[DemiMarie]

Thanks for the PR @ernst-qos!

[jevank]

I think it would be great to be able to connect tcp directly via qrexec-client-vm! It would also be great to do stdio queries without external applications similar to linux. Thanks @ernst-qos !

But I don't know if it would be safer to use a ported netcat than the built-in one.

I will try to test all of it.

[ernst-qos]

@jevank a ported netcat (without -e) would be great for handling incoming connections. That would mean we don't have to write a custom program to handle that.
For outgoing connections -e is required to pipe netcat's STDIO to qrexec-client-vm. And as is also mentioned on the netcat github page you link, Windows antivirus software does not like -e very much.

[DemiMarie]

I think implementing this in qrexec itself is a better approach than relying on an external netcat command. Process creation on Windows is slow, for one.

[jevank]

Sorry for the long delay. I've tried build from CI, changes don't break it, but can't be fully tested because of excluded stdio forward utility. Hope to make complete tests soon.

For outgoing connections -e is required to pipe netcat's STDIO to qrexec-client-vm. And as is also mentioned on the netcat github page you link, Windows antivirus software does not like -e very much.

Right. On second thought, I agree that qrexec-client-vm, run by a user with his privileges, looks fine with network activity.

[ernst-qos]

I also added a service for incoming qubes.ConnectTCP.

Both incoming and outgoing connections have been tested.

1. Outgoing has been tested with bulk and latency sensitive applications.
2. Incoming has only been tested with moving some large file (at 10MB/s per connection) but not with latency sensitive applications as I don't have any at hand.

@jevank I am compiling it as part of https://github.com/QubesOS/qubes-windows-tools-cross and for now I am just copying over the binaries.