Windows client: PostUp/PreDown possible?

[Mark Schmidt]

Am 10.12.2019 um 20:22 schrieb Jason A. Donenfeld:
> We'd considered it, but the fear is that it will be used to spread
> malware and RCE. Linux command line users can generally be trusted to
> check the config files they're writing into /etc/wireguard, but I
> don't have that same feeling about plug-and-chug Windows users
> pointing and clicking their way to BonziBuddy. That's possibly a bit
> of a patronizing perspective, I realize, but the potential for havoc
> is pretty high.
> 
> Thoughts?

I think if you want the client to be useable, you should do it. 
Otherwise, someone else will implement it. TunSafe, for instance, has 
the options. So would a user or organisation be better off switching to 
that software if they need this feature? Or would it not be better 
overall to incentivise the use of the *official* client?

Just giving you my personal experience. That's what I did. The software 
didn't do what I wanted, so my first instinct was to look for another 
software. Which lead me to TunSafe. I eventually decided against it and 
kept using Wireguard for Windows anyway (for reasons stated below), but 
that's what happens in these cases.

Also, I've noticed that the GUI won't work under normal user accounts. 
Only members of the admin group can activate and deactivate tunnels. 
Meaning: Everyone who wants to use the GUI (the plug and play Windows 
dummies) is forced to always work with admin privileges. While many 
people do that anyway (so many in fact that MS had to introduce the UAC 
as a band-aid), it's still not so great for security. Yet evidently not 
considered a problem for Wireguard. So it seems like a bit of a double 
standard. No offense.

And when people try to work around the limitation, they might also 
create additional issues. Even if it's just in the form of increased 
complexity.

Case in point: The way I worked around the limitation was to a use 
wrapper script that calls Wireguard from the command line via surun (a 
third party program that is kind of like 'sudo' for Windows) so that the 
user doesn't have to be admin, then waits for the server to show up and 
connects to it. It works, but I wouldn't call it pretty.

For anyone interested in the solution - for lack of a better term -, 
this is the "connect" script (bells and whistles - like error handling - 
omitted):

,----
| surun "C:\Program Files\Wireguard\wireguard.exe" ^
|   /installtunnelservice "C:\Users\Public\Documents\mytunnel.conf"
| :ping
| timeout /t 1 /nobreak >NUL
| (ping -n 1 10.0.0.1 | find "TTL=" >NUL) || goto ping
| net use z: \\10.0.0.1\data
`----

And likewise, the "disconnect" scripts looks like this:

,----
| net use z: /delete /yes
| surun "C:\Program Files\Wireguard\wireguard" ^
|   /uninstalltunnelservice "mytunnel"
`----

Some PostUp/PreDown commands would probably be more elegant.

Even if I grant that the security concerns are valid, other ways to 
mitigate them exist. For example: I for one would be perfectly ok if the 
options were ignored by default and you'd have to manually enable them 
somewhere first. Maybe acknowledging you're using them at your own risk. 
TunSafe does that, by the way. You have to check a box in the menu 
before you can use the options. That seems like a reasonable compromise.


By the way: The way that TunSafe implements these options is not well 
suited for what I want to do. It runs the PostUp command after the 
interface has been set up, but before the tunnel is up. So a script 
trying to connect to a network share will not find the server. And it 
also can't just ping the server until it's available and connect then. 
Because TunSafe always waits for the command to finish before it 
continues. That creates a deadlock (TunSafe waits for the script, and 
the script waits for the server, which won't appear because TunSafe is 
waiting). Even using the 'start' command from Windows (which launches a 
program in the background, sort of like adding an '&' in a Linux shell) 
does not work.

So I would suggest an option that's either run after IP connectivity is 
established. Or at least one that doesn't (necessarily) block. I can see 
why waiting for the command to finish before actually creating the 
tunnel could be useful in some cases. But not in every case, so a little 
bit of flexibility might be warranted.