* Re: Windows client: PostUp/PreDown possible?
2019-12-10 19:22 ` Jason A. Donenfeld
@ 2019-12-11 1:07 ` Mark Schmidt
0 siblings, 0 replies; 4+ messages in thread
From: Mark Schmidt @ 2019-12-11 1:07 UTC (permalink / raw)
To: wireguard
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.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply [flat|nested] 4+ messages in thread