Development discussion of WireGuard
 help / color / mirror / Atom feed
* Using WireGuard on Windows as non-admin - proper solution?
@ 2020-11-12 15:18 vh217
  2020-11-13  2:16 ` Jason A. Donenfeld
  2020-11-21 10:05 ` Jason A. Donenfeld
  0 siblings, 2 replies; 39+ messages in thread
From: vh217 @ 2020-11-12 15:18 UTC (permalink / raw)
  To: wireguard

Hello,

I've been wondering about using WireGuard on Windows as a non-admin user.

I have seen Jason's reply in this regard [1] and I understand the 
rationale. This however effectively means that WireGuard can't be 
directly used on company-issued machines where users who need to connect 
to company servers are usually not given administrator rights.

So I would like to open up two discussion points:
1) Is this use case something WireGuard was even meant for? I.e. should 
we even try to bend wg to be able to do this kind of stuff?
2) If the answer is yes, what would be the least hacky/workaround-ey way 
to do it?

I found a couple solutions on the Internet to this problem [2], [3] but 
both of them seem to be kind of complicated for setting up with dozens 
of clients.

In my mind there are two ways about the solution:
1) Somehow allow the user to be able to perform this one administrative 
task.
2) Since wg is essentially quiet when not being used, leave the wg 
tunnel on at all times. (aka "fire [up] and forget")

The 1) is more or less covered in the solutions in [2] and [3] so that 
doesn't seem like a way if we want something easy.
That leaves us with 2) which seems to work fine, although we've run into 
an issue with overlapping routes, i.e. if the remote company LAN is 
something like 192.168.1.0/24 and wg server 172.17.1.1 and the wg adds a 
route "192.168.1.0/24 via 172.17.1.1" then when the client is physically 
present in the company their LAN stops working. This could probably be 
easily fixed by setting up route metric as a PostUp, though my 
Windows-route-fu is weak in this one.

Any input on this would be greatly appreciated, since the info on the 
Internet seems to be rather scattered around.

Also, if anyone has an idea on how to modify the route metric in the 
PostUp, I think that might be an elegant solution to this.

Thanks!

Viktor

[1] https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg04292.html
[2] 
https://www.reddit.com/r/WireGuard/comments/frizel/solution_managing_wireguard_on_windows_as_a/
[3] https://www.henrychang.ca/how-to-setup-wireguard-vpn-server-on-windows/



^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-12 15:18 Using WireGuard on Windows as non-admin - proper solution? vh217
@ 2020-11-13  2:16 ` Jason A. Donenfeld
  2020-11-13 12:03   ` Der PCFreak
                     ` (3 more replies)
  2020-11-21 10:05 ` Jason A. Donenfeld
  1 sibling, 4 replies; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-13  2:16 UTC (permalink / raw)
  To: vh217; +Cc: WireGuard mailing list

Hi Viktor,

I am actually interested in solving this. I took an initial stab at it
here, but I'm not super comfortable with the implementation or the
security implications:
https://git.zx2c4.com/wireguard-windows/commit/?h=jd/unprivd-knob

Aside from doing this from within our existing UI, the general
solution using the service-based building blocks is to simply allow
users to start and stop services that begin with "WireGuardTunnel$".
So the flow is something like:

1. wireguard /installtunnelservice  path\to\sometunnel.conf.
2. Change the ACLs on WireGuardTunnel$sometunnel to fit your user.
3. Have the user use `net start` and `net stop`, or similar, to
control whether the service is up or down.

That's not super pretty, but it should work, and it is automatable.
Meanwhile, I'll keep thinking about various ways to do this in a more
"first-party" way.

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-13  2:16 ` Jason A. Donenfeld
@ 2020-11-13 12:03   ` Der PCFreak
  2020-11-15 15:28   ` Patrik Holmqvist
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 39+ messages in thread
From: Der PCFreak @ 2020-11-13 12:03 UTC (permalink / raw)
  To: wireguard

Hi,

a long time ago (wow 7 years now) OpenVPN was facing the same problem 
and I had to come up with a solution at this time which I wrote down here:

https://community.openvpn.net/openvpn/wiki/Nonprivileged?__cf_chl_jschl_tk__=39af44f70f734e1518810bfa4f763b5614b5d0cd-1605268198-0-AdWjPrQmfW_DxRRmKq1ebg6_bp-ISgZpLzFFC-FpzH9anyH3NEa1vtRcZAv7sQ_qLE-1pXhvVutaGK0e_jcPKwRb51xZAJrDAX58ap_o39EO-mLClM-PiYlPBmvxS68mJASvxyInfI5IuXaPFl4Rm2VSYNWjiKCIxo-qP2GCZ5h74Z-qxkoGNg96mFsUabWVqrbCaw0GGPahl6iWDZdSETK3_UD_akuSpTVY58AauKyaaT3cGq-A9r-QsLYkJ9Q9fY_gvt03AgobKFi4_E4GMn9Imsc5VYNesNb6JwHJgvTtFP9C_dzN4OD3BZV_egUMVQ

especially the part "New and working solution for Windows 7 (and above)" 
- Sorry, the images are gone since Dropbox killed public folders but I 
still have them
somewhere lying arround.

I used Scheduled Tasks at logon of any user that automatically created 
another !privileged! scheduled task for the nonprivileged user and 
started OpenVPN.
It was a bit of a hack but it worked until first SecurePoint, then 
Sophos and finally OpenVPN.net came up with a client that communicated 
with a service and
did no longer need administrative privileges to bring up a connection.

I think you could reproduce the same with Wireguard using my old scripts 
posted above etc.

Not very nice but as always, time will tell.

Regards

Peter

On 13.11.2020 03:16, Jason A. Donenfeld wrote:
> Hi Viktor,
>
> I am actually interested in solving this. I took an initial stab at it
> here, but I'm not super comfortable with the implementation or the
> security implications:
> https://git.zx2c4.com/wireguard-windows/commit/?h=jd/unprivd-knob
>
> Aside from doing this from within our existing UI, the general
> solution using the service-based building blocks is to simply allow
> users to start and stop services that begin with "WireGuardTunnel$".
> So the flow is something like:
>
> 1. wireguard /installtunnelservice  path\to\sometunnel.conf.
> 2. Change the ACLs on WireGuardTunnel$sometunnel to fit your user.
> 3. Have the user use `net start` and `net stop`, or similar, to
> control whether the service is up or down.
>
> That's not super pretty, but it should work, and it is automatable.
> Meanwhile, I'll keep thinking about various ways to do this in a more
> "first-party" way.
>
> Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* RE: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-13  2:16 ` Jason A. Donenfeld
  2020-11-13 12:03   ` Der PCFreak
@ 2020-11-15 15:28   ` Patrik Holmqvist
  2020-11-19 16:56     ` Jason A. Donenfeld
  2020-11-17 10:18   ` Viktor H
  2020-11-26  7:09   ` Chris Bennett
  3 siblings, 1 reply; 39+ messages in thread
From: Patrik Holmqvist @ 2020-11-15 15:28 UTC (permalink / raw)
  To: Jason A. Donenfeld, vh217; +Cc: WireGuard mailing list

Hi!

We (Stockholm University) are also interested in a version that does not require local administrator permissions to start the application and handle tunnel configuration.
We are currently evaluating WireGuard as a VPN solution for our employees (and maybe students in the future) since we are not really happy with our current solution.

Unfortunately we ran into an issue that has been discussed on this list before, that WireGuard for Windows requires the user to be Local Admin on the machine in order to start the application.

We are not very keen on making all our users Local Admin on their managed machines, and we think we share that with most larger enterprise environments since it goes against best security practices [0] [1]. We thought that the builtin group "Network Configuration Operators" could be a good alternative to Local Admin as to who are allowed to manage WireGuard. So we decided to try it out and patched the code, see diff below. (This was just to test the concept. We do not claim that this is a good solution, but it was what we managed to produced with limited time and knowledge)

From our test it seems to work, the users in the NCO group are fully allowed to manage the tunnels. The installation is of course required to be done by a Local Admin or as in our setup by SCCM [2]. 

Do you think you could implement something like this to the upstream version of WireGuard in order to allow larger organizations to easier roll out WireGuard in a more selective manner? We are also fine with removing the requirement to be a member of any particular group if that could be achieved.

[0] https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
[1] https://www.bleepingcomputer.com/news/microsoft/removing-user-admin-rights-mitigates-94-percent-of-all-critical-microsoft-vulnerabilities/
[2] https://en.wikipedia.org/wiki/Microsoft_System_Center_Configuration_Manager

Best regards and thank you for all the fine work with this great product!

--
Patrik

---
elevate/membership.go | 24 +++++++++++++++++++-----
main.go               |  2 ++
2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/elevate/membership.go b/elevate/membership.go
index 07c2ef69..c1fdcb7b 100644
--- a/elevate/membership.go
+++ b/elevate/membership.go
@@ -14,14 +14,28 @@ func isAdmin(token windows.Token) bool {
                             if err != nil {
                                                          return false
                             }
-                           var checkableToken windows.Token
-                           err = windows.DuplicateTokenEx(token, windows.TOKEN_QUERY|windows.TOKEN_IMPERSONATE, nil, windows.SecurityIdentification, windows.TokenImpersonation, &checkableToken)
+                          builtinNetworkOperatorsGroup, err := windows.CreateWellKnownSid(windows.WinBuiltinNetworkConfigurationOperatorsSid)
                             if err != nil {
                                                          return false
                             }
-                           defer checkableToken.Close()
-                           isAdmin, err := checkableToken.IsMember(builtinAdminsGroup)
-                           return isAdmin && err == nil
+                          var checkableAdminToken windows.Token
+                          var checkableNetworkOperatorsToken windows.Token
+                          defer checkableAdminToken.Close()
+                          defer checkableNetworkOperatorsToken.Close()
+                          err = windows.DuplicateTokenEx(token, windows.TOKEN_QUERY|windows.TOKEN_IMPERSONATE, nil, windows.SecurityIdentification, windows.TokenImpersonation, &checkableAdminToken)
+                          if err != nil {
+                                                       return false
+                          }
+                          err = windows.DuplicateTokenEx(token, windows.TOKEN_QUERY|windows.TOKEN_IMPERSONATE, nil, windows.SecurityIdentification, windows.TokenImpersonation, &checkableNetworkOperatorsToken)
+                          if err != nil {
+                                                       return false
+                          }
+                          isAdmin, err := checkableAdminToken.IsMember(builtinAdminsGroup)
+                          isNetworkOperator, err := checkableNetworkOperatorsToken.IsMember(builtinNetworkOperatorsGroup)
+                          if isAdmin || isNetworkOperator {
+                                                       return true && err == nil
+                          }
+                          return false && err == nil
}

func TokenIsElevatedOrElevatable(token windows.Token) bool {
diff --git a/main.go b/main.go
index 79dfcdfc..e8a48e8e 100644
--- a/main.go
+++ b/main.go
@@ -78,6 +78,7 @@ func checkForAdminGroup() {
                             }
                             defer processToken.Close()
                             if !elevate.TokenIsElevatedOrElevatable(processToken) {
+                                                       // TODO Logic for multiple groups needs to be added for the correct error message to be displayed
                                                          fatalf("WireGuard may only be used by users who are a member of the Builtin %s group.", elevate.AdminGroupName())
                             }
}
@@ -85,6 +86,7 @@ func checkForAdminGroup() {
func checkForAdminDesktop() {
                             adminDesktop, err := elevate.IsAdminDesktop()
                             if !adminDesktop && err == nil {
+                                                       // TODO Logic for multiple groups needs to be added for the correct error message to be displayed
                                                          fatalf("WireGuard is running, but the UI is only accessible from desktops of the Builtin %s group.", elevate.AdminGroupName())
                             }
}
-- 
2.20.1

-----Original Message-----
From: WireGuard <wireguard-bounces@lists.zx2c4.com> On Behalf Of Jason A. Donenfeld
Sent: den 13 november 2020 03:16
To: vh217@werehub.org
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Using WireGuard on Windows as non-admin - proper solution?

Hi Viktor,

I am actually interested in solving this. I took an initial stab at it here, but I'm not super comfortable with the implementation or the security implications:
https://git.zx2c4.com/wireguard-windows/commit/?h=jd/unprivd-knob

Aside from doing this from within our existing UI, the general solution using the service-based building blocks is to simply allow users to start and stop services that begin with "WireGuardTunnel$".
So the flow is something like:

1. wireguard /installtunnelservice  path\to\sometunnel.conf.
2. Change the ACLs on WireGuardTunnel$sometunnel to fit your user.
3. Have the user use `net start` and `net stop`, or similar, to control whether the service is up or down.

That's not super pretty, but it should work, and it is automatable.
Meanwhile, I'll keep thinking about various ways to do this in a more "first-party" way.

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-13  2:16 ` Jason A. Donenfeld
  2020-11-13 12:03   ` Der PCFreak
  2020-11-15 15:28   ` Patrik Holmqvist
@ 2020-11-17 10:18   ` Viktor H
  2020-11-26  7:09   ` Chris Bennett
  3 siblings, 0 replies; 39+ messages in thread
From: Viktor H @ 2020-11-17 10:18 UTC (permalink / raw)
  To: wireguard

Hello,

Jason, thanks for a quick reply and a PoC. I have tested it and it seems 
to work fine.
(small note: non-admin user can't Activate the tunnel via systray 
context menu, they have to open up GUI and click "Activate"; 
deactivation via systray context menu works)

As for the concept itself, I feel I am not qualified to judge the 
security implication of this solution since my knowledge of Windows 
security and network internals are next to none.

I have also tested increasing metric on the wg interface above the 
metric of local link with the same IP subnet [1] and that also seemed to 
work, therefore enabling the option for "always-on" setup.
I have however experienced that there might be a problem in the case of 
pushed DNS server since it might hinder normal (non-VPN-related) usage 
of the Internet, e.g. in the case the pushed DNS server does not resolve 
IPv6 addresses but the client does have IPv6 connectivity.

It seems that the "Network Configuration Operator" as Patrik Kolmqvist 
suggested might be one of the routes to do it properly. OpenVPN afaik 
uses its own group "OpenVPN Administrators" for this kind of thing [2] 
though again, I am not experienced enough to be able to consider 
security of this approach.

Finally thanks for pointing out the ACL setting for the service option, 
that seems to be similar or equal to the solution on Reddit I posted 
earlier, so I'll look into it further.

Thanks everyone.

Viktor

[1] 
https://docs.microsoft.com/en-us/powershell/module/nettcpip/set-netipinterface?view=win10-ps
[2] https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI-New#gui-group

On 13.11.2020 3:16, Jason A. Donenfeld wrote:
> Hi Viktor,
>
> I am actually interested in solving this. I took an initial stab at it
> here, but I'm not super comfortable with the implementation or the
> security implications:
> https://git.zx2c4.com/wireguard-windows/commit/?h=jd/unprivd-knob
>
> Aside from doing this from within our existing UI, the general
> solution using the service-based building blocks is to simply allow
> users to start and stop services that begin with "WireGuardTunnel$".
> So the flow is something like:
>
> 1. wireguard /installtunnelservice  path\to\sometunnel.conf.
> 2. Change the ACLs on WireGuardTunnel$sometunnel to fit your user.
> 3. Have the user use `net start` and `net stop`, or similar, to
> control whether the service is up or down.
>
> That's not super pretty, but it should work, and it is automatable.
> Meanwhile, I'll keep thinking about various ways to do this in a more
> "first-party" way.
>
> Jason


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-15 15:28   ` Patrik Holmqvist
@ 2020-11-19 16:56     ` Jason A. Donenfeld
  2020-11-20 11:49       ` Patrik Holmqvist
  0 siblings, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-19 16:56 UTC (permalink / raw)
  To: Patrik Holmqvist; +Cc: vh217, WireGuard mailing list

Hi Patrik,

Thanks for the patch. I think we'll probably take a route similar to
that, with S-1-5-32-556, but will gate it behind a registry knob and
and will allow only for starting/stopping/viewingstatus of tunnels,
but not editing or extracting private keys.

Would that be passable for you?

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* RE: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-19 16:56     ` Jason A. Donenfeld
@ 2020-11-20 11:49       ` Patrik Holmqvist
  2020-11-20 12:52         ` Jason A. Donenfeld
  0 siblings, 1 reply; 39+ messages in thread
From: Patrik Holmqvist @ 2020-11-20 11:49 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: vh217, WireGuard mailing list

Hi Jason and thanks for the reply!

I will describe our current workflow below:
* The WireGuard client is installed on the computer with our deployment solution
* The user logs in with SSO in our web-front [0] where they can generate one or more configs (for example one for their Windows computer and one for their phone)
* They download the config from the web-front
* Start WireGuard and import the configuration file
* Activates the tunnel when needed

Not sure if your suggested solution would allow for this? Maybe there could be different levels of permissions depending on the value you configure the registry key to or something.

[0] https://github.com/EmbarkStudios/wg-ui

/Best regards
Patrik

-----Original Message-----
From: Jason A. Donenfeld <Jason@zx2c4.com> 
Sent: den 19 november 2020 17:56
To: Patrik Holmqvist <patrik.holmqvist@su.se>
Cc: vh217@werehub.org; WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Using WireGuard on Windows as non-admin - proper solution?

Hi Patrik,

Thanks for the patch. I think we'll probably take a route similar to that, with S-1-5-32-556, but will gate it behind a registry knob and and will allow only for starting/stopping/viewingstatus of tunnels, but not editing or extracting private keys.

Would that be passable for you?

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-20 11:49       ` Patrik Holmqvist
@ 2020-11-20 12:52         ` Jason A. Donenfeld
  2020-11-20 13:10           ` Patrick Fogarty
  2020-11-20 13:14           ` Patrik Holmqvist
  0 siblings, 2 replies; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-20 12:52 UTC (permalink / raw)
  To: Patrik Holmqvist; +Cc: vh217, WireGuard mailing list

Hi Patrik,

Why not provision the config for the users when you're provisioning
the rest of the machine for their ownership?

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-20 12:52         ` Jason A. Donenfeld
@ 2020-11-20 13:10           ` Patrick Fogarty
  2020-11-20 13:14           ` Patrik Holmqvist
  1 sibling, 0 replies; 39+ messages in thread
From: Patrick Fogarty @ 2020-11-20 13:10 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: Patrik Holmqvist, vh217, WireGuard mailing list

Jason

That method has the challenge of having to get a static configuration 
correct at the time of provisioning. A perfect example of when that 
won't work is during COVID. We have had client offices shut down, 
requiring us to migrate the VPN endpoint to a different office of the 
client. A machine in the field needs different configurations at that point.

You mentioned in a previous email you do not like the idea of allowing 
users to be able to change default routes. That was the reasoning behind 
requiring admin rights. Extremely valid point. With tools we have 
written in-house for matters unrelated to WireGuard we write them so 
config files cannot be loaded unless they are digitally signed with 
approved certificates, thereby allowing non-admins the ability to apply 
configuration files while on the road beyond our reach. It constrains 
what the user can do to what we distribute. The theory is, if we do our 
job correctly the user cannot hurt themselves. So far so good.


Patrick Fogarty


Jason A. Donenfeld wrote on 11/20/2020 7:52 AM:
> Hi Patrik,
>
> Why not provision the config for the users when you're provisioning
> the rest of the machine for their ownership?
>
> Jason
>




^ permalink raw reply	[flat|nested] 39+ messages in thread

* RE: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-20 12:52         ` Jason A. Donenfeld
  2020-11-20 13:10           ` Patrick Fogarty
@ 2020-11-20 13:14           ` Patrik Holmqvist
  1 sibling, 0 replies; 39+ messages in thread
From: Patrik Holmqvist @ 2020-11-20 13:14 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: vh217, WireGuard mailing list

Hi Jason

In the University world there is a lot of "academic freedom" and we (the central IT-department) don’t manage all computer at the university.
We also don’t have any central management of phones for example.

So we built this solution so that it would work the same way for all use cases and device types, not just those devices managed by central IT.

But maybe we need to re-think how we do this and download the config dynamically for the user when they install the client or something.

/Best Regards
Patrik

-----Original Message-----
From: Jason A. Donenfeld <Jason@zx2c4.com> 
Sent: den 20 november 2020 13:52
To: Patrik Holmqvist <patrik.holmqvist@su.se>
Cc: vh217@werehub.org; WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Using WireGuard on Windows as non-admin - proper solution?

Hi Patrik,

Why not provision the config for the users when you're provisioning the rest of the machine for their ownership?

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-12 15:18 Using WireGuard on Windows as non-admin - proper solution? vh217
  2020-11-13  2:16 ` Jason A. Donenfeld
@ 2020-11-21 10:05 ` Jason A. Donenfeld
  2020-11-22 12:55   ` Jason A. Donenfeld
  2020-11-24 23:42   ` Riccardo Paolo Bestetti
  1 sibling, 2 replies; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-21 10:05 UTC (permalink / raw)
  To: vh217; +Cc: WireGuard mailing list

Hi,

Check out the recent changes in git master, still under development,
but functional at this point:

https://git.zx2c4.com/wireguard-windows/about/adminregistry.md

You'll need to build from source to try this, but that should be pretty easy:

git clone https://git.zx2c4.com/wireguard-windows
cd wireguard-windows
.\build.bat
taskkill /im wireguard.exe /f
amd64\wireguard.exe

I may remove this before 0.3, or implement it totally differently, but
that's the general sketch.

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-21 10:05 ` Jason A. Donenfeld
@ 2020-11-22 12:55   ` Jason A. Donenfeld
  2020-11-23 14:57     ` Fatih USTA
  2020-11-24 23:42   ` Riccardo Paolo Bestetti
  1 sibling, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-22 12:55 UTC (permalink / raw)
  To: vh217; +Cc: WireGuard mailing list

This too is a work in progress, but should give some idea of what's coming:

https://git.zx2c4.com/wireguard-windows/about/enterprise.md

Does it seem like this set of capabilities is suitable for what you
have in mind?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-22 12:55   ` Jason A. Donenfeld
@ 2020-11-23 14:57     ` Fatih USTA
  0 siblings, 0 replies; 39+ messages in thread
From: Fatih USTA @ 2020-11-23 14:57 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

Hi,

I have an idea but I'm not sure if this is a correct and safe solution.

When you want to install an application, you must obtain permission from 
UAC. If you have permission for the first installation, you can install 
everything.

Idea is here.
In the first installation, we will install wg-net-service with pipe 
socket with the "system" account. This service will handle network 
options (add / remove route, dns, etc.).
Wireguard uses this service via the pipe socket for communication when 
the tunnel is up or down. So you don't need any permission.

Regards.

Fatih USTA

On 22.11.2020 15:55, Jason A. Donenfeld wrote:
> This too is a work in progress, but should give some idea of what's coming:
>
> https://git.zx2c4.com/wireguard-windows/about/enterprise.md
>
> Does it seem like this set of capabilities is suitable for what you
> have in mind?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-21 10:05 ` Jason A. Donenfeld
  2020-11-22 12:55   ` Jason A. Donenfeld
@ 2020-11-24 23:42   ` Riccardo Paolo Bestetti
  2020-11-25  1:08     ` Jason A. Donenfeld
  2020-11-25 12:40     ` AW: Using WireGuard on Windows as non-admin - proper solution? Joachim Lindenberg
  1 sibling, 2 replies; 39+ messages in thread
From: Riccardo Paolo Bestetti @ 2020-11-24 23:42 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

On Sat Nov 21, 2020 at 11:05 AM CET, Jason A. Donenfeld wrote:
> Hi,
>
> Check out the recent changes in git master, still under development,
> but functional at this point:
>
> https://git.zx2c4.com/wireguard-windows/about/adminregistry.md
Please note that unfortunately the S-1-5-32-556 group doesn't exist in
all Windows editions. For example, it does not exist in Windows 10 Home.

The general idea is fine, and that group could very well be the default
one; however it might be useful to also have a registry key to pick a
different SID.

Riccardo P. Bestetti


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-24 23:42   ` Riccardo Paolo Bestetti
@ 2020-11-25  1:08     ` Jason A. Donenfeld
  2020-11-25  7:49       ` Riccardo Paolo Bestetti
  2020-11-25 12:40     ` AW: Using WireGuard on Windows as non-admin - proper solution? Joachim Lindenberg
  1 sibling, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-25  1:08 UTC (permalink / raw)
  To: Riccardo Paolo Bestetti; +Cc: WireGuard mailing list

Hi Riccardo,

Interesting consideration. I didn't know that.

Can you not add that group manually need be?

Are there relevant use cases for "home" users using this feature?

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-25  1:08     ` Jason A. Donenfeld
@ 2020-11-25  7:49       ` Riccardo Paolo Bestetti
  2020-11-25 10:30         ` Jason A. Donenfeld
  0 siblings, 1 reply; 39+ messages in thread
From: Riccardo Paolo Bestetti @ 2020-11-25  7:49 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

On Wed Nov 25, 2020 at 2:08 AM CET, Jason A. Donenfeld wrote:
> Hi Riccardo,
>
> Interesting consideration. I didn't know that.
I didn't know that either until I tried to deploy WireGuard on a laptop
yesterday! It seems not to be documented anywhere.

The group has been around since Windows XP afaik, however I have no idea
whether the associated licesing chicanery has also been around that long.

>
> Can you not add that group manually need be?
I'm not an expert on Windows, but a quick lookup on the net suggests you
cannot create a local group with a specific SID.

Since the group is looked up by SID - which is the correct way -:
  operatorGroupSid, _ := windows.CreateWellKnownSid(
     windows.WinBuiltinNetworkConfigurationOperatorsSid)
I don't think this can be fixed in any (non-meddle-with-internals) way.

>
> Are there relevant use cases for "home" users using this feature?
Probably not home users, but user using the Home edition of the OS -
definitely yes.

I do some sysadmin work for small to medium sized companies, and it
happens quite often to come across "throwaway" low-cost roadwarrior
machines running Home edition.

Lately, due to the pandemic, I've had to set up a few machines with
WireGuard in a hurry (read: without due preparation and testing). 0.3
has been great news, as before that I was forced to add user accounts to
the Administrators group to allow users to connect. But I quickly
learned that this does not apply to machines running Home edition.

I understand that adding further knobs should be very carefully
considered. But I think that either this one needs to be added, or the
mechanism should be changed. For example, instead of having a on/off
registry entry, we could have an entry indicating the SID of the group
which has access to the limited UI, and its presence would indicate that
the feature should be enabled.

Riccardo


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-25  7:49       ` Riccardo Paolo Bestetti
@ 2020-11-25 10:30         ` Jason A. Donenfeld
  2020-11-25 11:45           ` Jason A. Donenfeld
  0 siblings, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-25 10:30 UTC (permalink / raw)
  To: Riccardo Paolo Bestetti; +Cc: WireGuard mailing list

On 11/25/20, Riccardo Paolo Bestetti <pbl@bestov.io> wrote:
> On Wed Nov 25, 2020 at 2:08 AM CET, Jason A. Donenfeld wrote:
>> Hi Riccardo,
>>
>> Interesting consideration. I didn't know that.
> I didn't know that either until I tried to deploy WireGuard on a laptop
> yesterday! It seems not to be documented anywhere.
>
> The group has been around since Windows XP afaik, however I have no idea
> whether the associated licesing chicanery has also been around that long.
>
>>
>> Can you not add that group manually need be?
> I'm not an expert on Windows, but a quick lookup on the net suggests you
> cannot create a local group with a specific SID.

I'm not convinced this is the case. We're talking about a local group.
Surely there's some on-disk representation of available groups and
associations, no? This line of inquiry needs to be fully exhausted
before we even consider alternatives.

Has Microsoft documented this limitation?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-25 10:30         ` Jason A. Donenfeld
@ 2020-11-25 11:45           ` Jason A. Donenfeld
  2020-11-25 14:08             ` Riccardo Paolo Bestetti
  0 siblings, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-25 11:45 UTC (permalink / raw)
  To: Riccardo Paolo Bestetti; +Cc: WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

On Wed, Nov 25, 2020 at 11:30 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On 11/25/20, Riccardo Paolo Bestetti <pbl@bestov.io> wrote:
> > On Wed Nov 25, 2020 at 2:08 AM CET, Jason A. Donenfeld wrote:
> >> Hi Riccardo,
> >>
> >> Interesting consideration. I didn't know that.
> > I didn't know that either until I tried to deploy WireGuard on a laptop
> > yesterday! It seems not to be documented anywhere.
> >
> > The group has been around since Windows XP afaik, however I have no idea
> > whether the associated licesing chicanery has also been around that long.
> >
> >>
> >> Can you not add that group manually need be?
> > I'm not an expert on Windows, but a quick lookup on the net suggests you
> > cannot create a local group with a specific SID.
>
> I'm not convinced this is the case. We're talking about a local group.
> Surely there's some on-disk representation of available groups and
> associations, no? This line of inquiry needs to be fully exhausted
> before we even consider alternatives.
>
> Has Microsoft documented this limitation?

Well, I made Network Configuration Operators work just fine on Windows
10 Home edition. Here are the steps I followed, which I'm sure I could
compress into a single powershell script or executable need be:

1. Download psexec from the sysinternals page:
https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
2. Download nco.reg from the attachment in this email.
3. Open up an administrator console and type `psexec -i -s regedit`.
4. Choose File->Import and select the nco.reg file.
5. Add your user to the group like usual (e.g. `Add-LocalGroupMember
-Group "Network Configuration Operators" -Member MrDerp`).

I've confirmed that this works fine with the limited operator ui on
WireGuard for Windows 0.3.1.

Jason

[-- Attachment #2: nco.reg --]
[-- Type: text/x-ms-regedit, Size: 4226 bytes --]

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Builtin\Aliases\0000022C]
"C"=hex:2c,02,00,00,00,00,00,00,e8,00,00,00,03,00,01,00,e8,00,00,00,3e,00,00,\
  00,00,00,00,00,28,01,00,00,d8,00,00,00,00,00,00,00,00,02,00,00,1c,00,00,00,\
  01,00,00,00,01,00,14,80,c8,00,00,00,d8,00,00,00,14,00,00,00,44,00,00,00,02,\
  00,30,00,02,00,00,00,02,c0,14,00,13,00,05,01,01,01,00,00,00,00,00,01,00,00,\
  00,00,02,c0,14,00,ff,ff,1f,00,01,01,00,00,00,00,00,05,07,00,00,00,02,00,84,\
  00,04,00,00,00,00,00,14,00,0c,00,02,00,01,01,00,00,00,00,00,01,00,00,00,00,\
  00,00,18,00,1f,00,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00,00,\
  00,18,00,1f,00,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,24,02,00,00,00,00,\
  38,00,0c,00,02,00,01,0a,00,00,00,00,00,0f,03,00,00,00,00,04,00,00,de,a2,28,\
  67,21,3e,d2,af,19,ad,5d,79,b0,c1,07,29,27,56,fc,20,d8,ad,66,f6,10,f2,68,fa,\
  df,2a,f8,0f,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00,01,02,00,00,00,\
  00,00,05,20,00,00,00,20,02,00,00,4e,00,65,00,74,00,77,00,6f,00,72,00,6b,00,\
  20,00,43,00,6f,00,6e,00,66,00,69,00,67,00,75,00,72,00,61,00,74,00,69,00,6f,\
  00,6e,00,20,00,4f,00,70,00,65,00,72,00,61,00,74,00,6f,00,72,00,73,00,00,00,\
  4d,00,65,00,6d,00,62,00,65,00,72,00,73,00,20,00,69,00,6e,00,20,00,74,00,68,\
  00,69,00,73,00,20,00,67,00,72,00,6f,00,75,00,70,00,20,00,63,00,61,00,6e,00,\
  20,00,68,00,61,00,76,00,65,00,20,00,73,00,6f,00,6d,00,65,00,20,00,61,00,64,\
  00,6d,00,69,00,6e,00,69,00,73,00,74,00,72,00,61,00,74,00,69,00,76,00,65,00,\
  20,00,70,00,72,00,69,00,76,00,69,00,6c,00,65,00,67,00,65,00,73,00,20,00,74,\
  00,6f,00,20,00,6d,00,61,00,6e,00,61,00,67,00,65,00,20,00,63,00,6f,00,6e,00,\
  66,00,69,00,67,00,75,00,72,00,61,00,74,00,69,00,6f,00,6e,00,20,00,6f,00,66,\
  00,20,00,6e,00,65,00,74,00,77,00,6f,00,72,00,6b,00,69,00,6e,00,67,00,20,00,\
  66,00,65,00,61,00,74,00,75,00,72,00,65,00,73,00,01,05,00,00,00,00,00,05,15,\
  00,00,00,a8,93,d1,46,16,fe,89,a7,56,ec,96,97,ed,03,00,00

[HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Builtin\Aliases\Names\Network Configuration Operators]
@=hex(22c):


^ permalink raw reply	[flat|nested] 39+ messages in thread

* AW: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-24 23:42   ` Riccardo Paolo Bestetti
  2020-11-25  1:08     ` Jason A. Donenfeld
@ 2020-11-25 12:40     ` Joachim Lindenberg
  2020-11-25 13:08       ` Jason A. Donenfeld
  1 sibling, 1 reply; 39+ messages in thread
From: Joachim Lindenberg @ 2020-11-25 12:40 UTC (permalink / raw)
  To: 'WireGuard mailing list'

On Windows home you can almost safely assume the local user is member of Administrators, thus testing for membership in S-1-5-32-556 (for Pro and up) or S-1-5-32-544 might do the trick.
Regards,
Joachim

-----Ursprüngliche Nachricht-----
Von: WireGuard <wireguard-bounces@lists.zx2c4.com> Im Auftrag von Riccardo Paolo Bestetti
Gesendet: Wednesday, 25 November 2020 00:43
An: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Betreff: Re: Using WireGuard on Windows as non-admin - proper solution?

On Sat Nov 21, 2020 at 11:05 AM CET, Jason A. Donenfeld wrote:
> Hi,
>
> Check out the recent changes in git master, still under development, 
> but functional at this point:
>
> https://git.zx2c4.com/wireguard-windows/about/adminregistry.md
Please note that unfortunately the S-1-5-32-556 group doesn't exist in all Windows editions. For example, it does not exist in Windows 10 Home.

The general idea is fine, and that group could very well be the default one; however it might be useful to also have a registry key to pick a different SID.

Riccardo P. Bestetti



^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-25 12:40     ` AW: Using WireGuard on Windows as non-admin - proper solution? Joachim Lindenberg
@ 2020-11-25 13:08       ` Jason A. Donenfeld
  0 siblings, 0 replies; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-25 13:08 UTC (permalink / raw)
  To: Joachim Lindenberg; +Cc: WireGuard mailing list

On Wed, Nov 25, 2020 at 2:05 PM Joachim Lindenberg
<joachim@lindenberg.one> wrote:
>
> On Windows home you can almost safely assume the local user is member of Administrators, thus testing for membership in S-1-5-32-556 (for Pro and up) or S-1-5-32-544 might do the trick.

That accomplishes nothing. The full UI is already shown to
administrators. Riccardo's inquiry concerns the limited UI mode, which
is for the NCO group. Conflating the two groups doesn't make any
sense.

And, there's already a solution posted on this thread regarding Home edition.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-25 11:45           ` Jason A. Donenfeld
@ 2020-11-25 14:08             ` Riccardo Paolo Bestetti
       [not found]               ` <8bf9e364f87bd0018dabca03dcc8c19b@mail.gmail.com>
  0 siblings, 1 reply; 39+ messages in thread
From: Riccardo Paolo Bestetti @ 2020-11-25 14:08 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

On Wed Nov 25, 2020 at 12:45 PM CET, Jason A. Donenfeld wrote:
> On Wed, Nov 25, 2020 at 11:30 AM Jason A. Donenfeld <Jason@zx2c4.com>
> wrote:
> >
> > On 11/25/20, Riccardo Paolo Bestetti <pbl@bestov.io> wrote:
> > > On Wed Nov 25, 2020 at 2:08 AM CET, Jason A. Donenfeld wrote:
> > >> Can you not add that group manually need be?
> > > I'm not an expert on Windows, but a quick lookup on the net suggests you
> > > cannot create a local group with a specific SID.
> >
> > I'm not convinced this is the case. We're talking about a local group.
> > Surely there's some on-disk representation of available groups and
> > associations, no? This line of inquiry needs to be fully exhausted
> > before we even consider alternatives.
> >
> > Has Microsoft documented this limitation?
>
> Well, I made Network Configuration Operators work just fine on Windows
> 10 Home edition.

Excellent. I will try to deploy this, hoping that it won't get nuked by
Windows updates.

Thank you for your help.
Riccardo


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
       [not found]               ` <8bf9e364f87bd0018dabca03dcc8c19b@mail.gmail.com>
  2020-11-25 20:10                 ` Riccardo Paolo Bestetti
@ 2020-11-25 21:42                 ` Jason A. Donenfeld
  2020-11-26  8:53                   ` Adrian Larsen
  1 sibling, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-25 21:42 UTC (permalink / raw)
  To: Clint Dovholuk; +Cc: Riccardo Paolo Bestetti, WireGuard mailing list

On Wed, Nov 25, 2020 at 7:04 PM Clint Dovholuk
<clint.dovholuk@netfoundry.io> wrote:
>
> Out of curiosity - why not just use " S-1-5-4" Interactive - " A group that
> includes all users that have logged on interactively. Membership is
> controlled by the operating system."
>
> If the user logged on - let the turn the tunnel on/off?

I guess that's the same argument as, "why doesn't Microsoft let users
twiddle around with adapter settings and IP addresses if they're
interactive?" Apparently there was some imperative for having control
over this be more fine grained, so they provide the NCO group. Turning
on and off WireGuard tunnels seems akin to disabling and enabling
network adapters, in general, so linking the two seems coherent.

More concretely, some folks are deploying WireGuard in a much more
restricted setting, in which the end user has no control over when it
goes up or down; that's all decided by some remote service out of the
interactive user's purview. For some high sensitivity applications,
not letting interactive users disable WireGuard is desirable. For
other applications, it's the opposite. The NCO group seems to fit the
level of granularity we're after.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-13  2:16 ` Jason A. Donenfeld
                     ` (2 preceding siblings ...)
  2020-11-17 10:18   ` Viktor H
@ 2020-11-26  7:09   ` Chris Bennett
  3 siblings, 0 replies; 39+ messages in thread
From: Chris Bennett @ 2020-11-26  7:09 UTC (permalink / raw)
  To: WireGuard mailing list

Hi Jason,

Thanks for addressing this :)

I started the conversation a year ago [1] and was frustrated with the
response, but cobbled together scheduled task workaround and moved on.

But I'm very happy that the project's position on this has changed and
there is now a workable solution for non-admins.

Wireguard for Windows has been working perfectly for many of my users
during COVID lockdown, thanks again for all the great work.

Regards,

Chris

[1] https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg04265.html

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-25 21:42                 ` Jason A. Donenfeld
@ 2020-11-26  8:53                   ` Adrian Larsen
  2020-11-28 14:28                     ` Jason A. Donenfeld
  0 siblings, 1 reply; 39+ messages in thread
From: Adrian Larsen @ 2020-11-26  8:53 UTC (permalink / raw)
  To: Jason A. Donenfeld, Clint Dovholuk
  Cc: Riccardo Paolo Bestetti, WireGuard mailing list

One thing that is commonly implemented in other clients doing tunnels is 
the detection of "ON / OFF Corporate network".

Without any user intervention, the vpn client is capable to detect (on 
every network change) where the user is located and to active the client 
or not.

Values to detect are a combination of:

(usually you can do AND / OR of this values)

  1- Adapter domain (i.e. contoso.com) . This comes from DHCP values 
received.

2 - DNS servers IPs

3 - Hostname vs IP. (This is to create a local DNS A record on your 
internal DNS server that is resolvable only when you are ON corporate 
network and not outside)

The detection of this values are platform agnostic. You can use it on 
any client: Linux, Windows, Mac, etc; to detect when turn ON / OFF the 
vpn client automatically without user intervention.

Best regards

Adrian


On 25/11/2020 21:42, Jason A. Donenfeld wrote:
> On Wed, Nov 25, 2020 at 7:04 PM Clint Dovholuk
> <clint.dovholuk@netfoundry.io> wrote:
>> Out of curiosity - why not just use " S-1-5-4" Interactive - " A group that
>> includes all users that have logged on interactively. Membership is
>> controlled by the operating system."
>>
>> If the user logged on - let the turn the tunnel on/off?
> I guess that's the same argument as, "why doesn't Microsoft let users
> twiddle around with adapter settings and IP addresses if they're
> interactive?" Apparently there was some imperative for having control
> over this be more fine grained, so they provide the NCO group. Turning
> on and off WireGuard tunnels seems akin to disabling and enabling
> network adapters, in general, so linking the two seems coherent.
>
> More concretely, some folks are deploying WireGuard in a much more
> restricted setting, in which the end user has no control over when it
> goes up or down; that's all decided by some remote service out of the
> interactive user's purview. For some high sensitivity applications,
> not letting interactive users disable WireGuard is desirable. For
> other applications, it's the opposite. The NCO group seems to fit the
> level of granularity we're after.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-26  8:53                   ` Adrian Larsen
@ 2020-11-28 14:28                     ` Jason A. Donenfeld
  2020-11-29  9:30                       ` Adrian Larsen
  0 siblings, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-28 14:28 UTC (permalink / raw)
  To: Adrian Larsen
  Cc: Clint Dovholuk, Riccardo Paolo Bestetti, WireGuard mailing list

On Thu, Nov 26, 2020 at 9:53 AM Adrian Larsen
<alarsen@maidenheadbridge.com> wrote:
>
> One thing that is commonly implemented in other clients doing tunnels is
> the detection of "ON / OFF Corporate network".
>
> Without any user intervention, the vpn client is capable to detect (on
> every network change) where the user is located and to active the client
> or not.
>
> Values to detect are a combination of:
>
> (usually you can do AND / OR of this values)
>
>   1- Adapter domain (i.e. contoso.com) . This comes from DHCP values
> received.
>
> 2 - DNS servers IPs
>
> 3 - Hostname vs IP. (This is to create a local DNS A record on your
> internal DNS server that is resolvable only when you are ON corporate
> network and not outside)
>
> The detection of this values are platform agnostic. You can use it on
> any client: Linux, Windows, Mac, etc; to detect when turn ON / OFF the
> vpn client automatically without user intervention.

That sounds like it introduces a security vulnerability, in which you
send the magic unauthenticated packets, and voila, WireGuard
deactivates and you're sending data in the clear.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-28 14:28                     ` Jason A. Donenfeld
@ 2020-11-29  9:30                       ` Adrian Larsen
  2020-11-29 10:52                         ` Jason A. Donenfeld
  0 siblings, 1 reply; 39+ messages in thread
From: Adrian Larsen @ 2020-11-29  9:30 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Clint Dovholuk, Riccardo Paolo Bestetti, WireGuard mailing list

Yes, it is; and is widely common practice.

With Wireguard probably the best is to create a Peer only reachable when 
"ON corporate" network to test the condition and to take action after.



On 28/11/2020 14:28, Jason A. Donenfeld wrote:
> On Thu, Nov 26, 2020 at 9:53 AM Adrian Larsen
> <alarsen@maidenheadbridge.com> wrote:
>> One thing that is commonly implemented in other clients doing tunnels is
>> the detection of "ON / OFF Corporate network".
>>
>> Without any user intervention, the vpn client is capable to detect (on
>> every network change) where the user is located and to active the client
>> or not.
>>
>> Values to detect are a combination of:
>>
>> (usually you can do AND / OR of this values)
>>
>>    1- Adapter domain (i.e. contoso.com) . This comes from DHCP values
>> received.
>>
>> 2 - DNS servers IPs
>>
>> 3 - Hostname vs IP. (This is to create a local DNS A record on your
>> internal DNS server that is resolvable only when you are ON corporate
>> network and not outside)
>>
>> The detection of this values are platform agnostic. You can use it on
>> any client: Linux, Windows, Mac, etc; to detect when turn ON / OFF the
>> vpn client automatically without user intervention.
> That sounds like it introduces a security vulnerability, in which you
> send the magic unauthenticated packets, and voila, WireGuard
> deactivates and you're sending data in the clear.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29  9:30                       ` Adrian Larsen
@ 2020-11-29 10:52                         ` Jason A. Donenfeld
  2020-11-29 12:09                           ` Phillip McMahon
  0 siblings, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-29 10:52 UTC (permalink / raw)
  To: Adrian Larsen
  Cc: Clint Dovholuk, Riccardo Paolo Bestetti, WireGuard mailing list

>>> One thing that is commonly implemented in other clients
>> That sounds like it introduces a security vulnerability
> Yes, it is

I don't mean to be rude, but shouldn't the line of thought sort of
come to a natural end there? We're trying very hard not to be in the
business of creating security vulnerabilities, after all.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 10:52                         ` Jason A. Donenfeld
@ 2020-11-29 12:09                           ` Phillip McMahon
  2020-11-29 12:50                             ` Jason A. Donenfeld
  0 siblings, 1 reply; 39+ messages in thread
From: Phillip McMahon @ 2020-11-29 12:09 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Adrian Larsen, Clint Dovholuk, Riccardo Paolo Bestetti,
	WireGuard mailing list

Interesting thread to follow.

My larger concern here is that without an officially provided method
to run wg as non-admin on supported Windows platforms the following
may happen

1) Limited proliferation of wg in the huge corporate/SME space, or
similar cases where end-users are not admin and don't have access to
any form of admin entitlements, to provide modern management of VPN
config and security. This would be a huge miss. Network Configuration
Operators permissions would not be permissible in most orgs for
end-users.
2) Without that in a place a high probability of mutated versions of
wg existing all with varying quality of implementation for a non-admin
solution. This I think has the real potential to taint the reputation
of wg as a whole and misses out on a full native method to address
what I think is a huge use case to solve for.

I cannot imagine that the corporate and non-admin use case isn't on
the roadmap for wg. Maybe I am wrong, however, this thread doesn't
make that assumption any clearer.

On Sun, 29 Nov 2020 at 11:55, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> >>> One thing that is commonly implemented in other clients
> >> That sounds like it introduces a security vulnerability
> > Yes, it is
>
> I don't mean to be rude, but shouldn't the line of thought sort of
> come to a natural end there? We're trying very hard not to be in the
> business of creating security vulnerabilities, after all.



-- 
Use this contact page to send me encrypted messages and files

https://flowcrypt.com/me/phillipmcmahon

P.S. Drowning in email? Try SaneBox and take back control:
http://sanebox.com/t/old3m. I love it.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 12:09                           ` Phillip McMahon
@ 2020-11-29 12:50                             ` Jason A. Donenfeld
  2020-11-29 13:40                               ` Phillip McMahon
  0 siblings, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-29 12:50 UTC (permalink / raw)
  To: Phillip McMahon
  Cc: Adrian Larsen, Clint Dovholuk, Riccardo Paolo Bestetti,
	WireGuard mailing list

On Sun, Nov 29, 2020 at 1:09 PM Phillip McMahon
<phillip.mcmahon@gmail.com> wrote:
>
> Interesting thread to follow.
>
> My larger concern here is that without an officially provided method
> to run wg as non-admin on supported Windows platforms the following
> may happen

Maybe you should keep following the thread? There _is_ an officially
provided method, and it has been released, and you can go to
wireguard.com/install/ to download it and read all about it in the
release notes posted to this list. This topic is closed and the
discussion over.

Then Adrian Larsen decided to jump in and request a totally unrelated
feature, rather than starting a new thread for that. I indulged, and
here we are.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 12:50                             ` Jason A. Donenfeld
@ 2020-11-29 13:40                               ` Phillip McMahon
  2020-11-29 17:52                                 ` Jason A. Donenfeld
  0 siblings, 1 reply; 39+ messages in thread
From: Phillip McMahon @ 2020-11-29 13:40 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Adrian Larsen, Clint Dovholuk, Riccardo Paolo Bestetti,
	WireGuard mailing list

Hi Jason,

I have been following the wider thread and maybe I misunderstood but
believe the solution requires some registry tweaks and membership to
the Network Operators Group, along with Windows Home requiring the
creation of a group not officially supported on that platform. Correct
or not?

It was with all the in mind that I wrote the two points.

"The topic is closed and the discussion over". Seems a little over the
top Jason. A year ago you concluded there would never be a solution
for Windows outside of full admin. End of discussion. Now we have
something that isn't full admin. Clearly times and positions can
change. But you might still not be at the final version, you might
want to incorporate a little more of the experience of your members to
get there.

Phill

On Sun, 29 Nov 2020 at 13:50, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Sun, Nov 29, 2020 at 1:09 PM Phillip McMahon
> <phillip.mcmahon@gmail.com> wrote:
> >
> > Interesting thread to follow.
> >
> > My larger concern here is that without an officially provided method
> > to run wg as non-admin on supported Windows platforms the following
> > may happen
>
> Maybe you should keep following the thread? There _is_ an officially
> provided method, and it has been released, and you can go to
> wireguard.com/install/ to download it and read all about it in the
> release notes posted to this list. This topic is closed and the
> discussion over.
>
> Then Adrian Larsen decided to jump in and request a totally unrelated
> feature, rather than starting a new thread for that. I indulged, and
> here we are.



-- 
Use this contact page to send me encrypted messages and files

https://flowcrypt.com/me/phillipmcmahon

P.S. Drowning in email? Try SaneBox and take back control:
http://sanebox.com/t/old3m. I love it.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 13:40                               ` Phillip McMahon
@ 2020-11-29 17:52                                 ` Jason A. Donenfeld
  2020-11-29 19:44                                   ` Phillip McMahon
  2020-11-30 12:47                                   ` Probable Heresy ;-) Peter Whisker
  0 siblings, 2 replies; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-29 17:52 UTC (permalink / raw)
  To: Phillip McMahon
  Cc: Adrian Larsen, Clint Dovholuk, Riccardo Paolo Bestetti,
	WireGuard mailing list

Hi Phillip,

On Sun, Nov 29, 2020 at 2:40 PM Phillip McMahon
<phillip.mcmahon@gmail.com> wrote:
> I have been following the wider thread and maybe I misunderstood but
> believe the solution requires some registry tweaks and membership to
> the Network Operators Group, along with Windows Home requiring the
> creation of a group not officially supported on that platform. Correct
> or not?
>
> It was with all the in mind that I wrote the two points.

I must admit I misunderstood your first message. Sorry for that. I
understand you now to be questioning two things:

- That this is gated behind a registry key;
- That it works by using the network operators group.

The first point is something I could imagine changing down the line as
we learn more about the NCO group's usage. To start, and for now, I
prefer to put "risky" settings behind a flag.

But the latter point I'm much more hesitant to change. You recalled
that I was initially entirely wary of this feature all together. This
is true. It was only upon hearing the excellent idea of the NCO group
that it became tenable for me. The reason is that the NCO group is a
preexisting designation as part of the operating system that confers
these privileges. And there's an easy argument to be made that adding
the ability to stop/start tunnels does not add anything extra beyond
what NCO can already do (like changing IP addresses or disabling
adapters). Therefore, the brilliance of the NCO suggestion, in my
mind, was that we're not adding any additional holes to the Windows
security model. That makes it very compelling to me.

It seems like you want to go back to challenge the initial hesitation
again: maybe we _should_ add additional caveats to the existing
Windows model, you suggest. Maybe. But if we can avoid doing so, I
really would prefer that, and it seems like NCO group strikes a good
balance.

What's the situation you have in mind in which an administrator would
permit a user to enable and disable tunnels but would not permit the
other privileges conferred by NCO? What is the impedance mismatch that
you are thinking about?

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 17:52                                 ` Jason A. Donenfeld
@ 2020-11-29 19:44                                   ` Phillip McMahon
  2020-11-29 20:59                                     ` Jason A. Donenfeld
  2020-11-30 12:47                                   ` Probable Heresy ;-) Peter Whisker
  1 sibling, 1 reply; 39+ messages in thread
From: Phillip McMahon @ 2020-11-29 19:44 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Adrian Larsen, Clint Dovholuk, Riccardo Paolo Bestetti,
	WireGuard mailing list

Hey Jason,

Won't drag this already long and confusing thread out. Not challenging
the current implementation, just the notion that any other suggestion
is a dead end and the topic is closed.

I will continue to use wg daily and now add in the non-admin elements
to test those out too. Appreciate the progress here and all that hard
work.

Phill

On Sun, 29 Nov 2020 at 18:52, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi Phillip,
>
> On Sun, Nov 29, 2020 at 2:40 PM Phillip McMahon
> <phillip.mcmahon@gmail.com> wrote:
> > I have been following the wider thread and maybe I misunderstood but
> > believe the solution requires some registry tweaks and membership to
> > the Network Operators Group, along with Windows Home requiring the
> > creation of a group not officially supported on that platform. Correct
> > or not?
> >
> > It was with all the in mind that I wrote the two points.
>
> I must admit I misunderstood your first message. Sorry for that. I
> understand you now to be questioning two things:
>
> - That this is gated behind a registry key;
> - That it works by using the network operators group.
>
> The first point is something I could imagine changing down the line as
> we learn more about the NCO group's usage. To start, and for now, I
> prefer to put "risky" settings behind a flag.
>
> But the latter point I'm much more hesitant to change. You recalled
> that I was initially entirely wary of this feature all together. This
> is true. It was only upon hearing the excellent idea of the NCO group
> that it became tenable for me. The reason is that the NCO group is a
> preexisting designation as part of the operating system that confers
> these privileges. And there's an easy argument to be made that adding
> the ability to stop/start tunnels does not add anything extra beyond
> what NCO can already do (like changing IP addresses or disabling
> adapters). Therefore, the brilliance of the NCO suggestion, in my
> mind, was that we're not adding any additional holes to the Windows
> security model. That makes it very compelling to me.
>
> It seems like you want to go back to challenge the initial hesitation
> again: maybe we _should_ add additional caveats to the existing
> Windows model, you suggest. Maybe. But if we can avoid doing so, I
> really would prefer that, and it seems like NCO group strikes a good
> balance.
>
> What's the situation you have in mind in which an administrator would
> permit a user to enable and disable tunnels but would not permit the
> other privileges conferred by NCO? What is the impedance mismatch that
> you are thinking about?
>
> Jason



-- 
Use this contact page to send me encrypted messages and files

https://flowcrypt.com/me/phillipmcmahon

P.S. Drowning in email? Try SaneBox and take back control:
http://sanebox.com/t/old3m. I love it.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 19:44                                   ` Phillip McMahon
@ 2020-11-29 20:59                                     ` Jason A. Donenfeld
  2020-11-30 18:34                                       ` Riccardo Paolo Bestetti
  2022-04-22 20:21                                       ` zer0flash
  0 siblings, 2 replies; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-11-29 20:59 UTC (permalink / raw)
  To: Phillip McMahon
  Cc: Adrian Larsen, Clint Dovholuk, Riccardo Paolo Bestetti,
	WireGuard mailing list

On Sun, Nov 29, 2020 at 8:44 PM Phillip McMahon
<phillip.mcmahon@gmail.com> wrote:
> Won't drag this already long and confusing thread out. Not challenging
> the current implementation, just the notion that any other suggestion
> is a dead end and the topic is closed.

Alright. Well, if you do think of good reasons why NCO is not a good
match for unpriv'd WireGuard control, please let me know. The whole
basis of going that route is the apparent intuition that these two
types of things, network modification and tunnel up/down, are one and
the same. But if you have in mind a way where the analogy breaks down,
that'd be very interesting to learn and would potentially be grounds
for changing course.

Jason

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Probable Heresy ;-)
  2020-11-29 17:52                                 ` Jason A. Donenfeld
  2020-11-29 19:44                                   ` Phillip McMahon
@ 2020-11-30 12:47                                   ` Peter Whisker
  2020-12-02 13:40                                     ` Jason A. Donenfeld
  1 sibling, 1 reply; 39+ messages in thread
From: Peter Whisker @ 2020-11-30 12:47 UTC (permalink / raw)
  To: wireguard

Hi

I expect to be shot down regarding this suggestion, but has there been 
any thought given to adding and optionally allowing enabing of lz4-v2 
compression of the plaintext payload before Wireguard encryption?

The reason I ask is that I was doing some tests recently and was 
horrified to find that OpenVPN with it's lz4-v2 switched on seriously 
outperformed Wireguard by about 50% in my test case. Obviously YMMV 
depending on the data stream.

I believe that lz4-v2 is very fast and has no overhead in incompressible 
packets. I realise that there have been some attacks on compressed 
encrypted data (eg the CRIME and BReACH attacks on TLS) but I don't know 
if they apply here.

Just wondering if there is a reason why it has not been done?

Regards

Peter



^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 20:59                                     ` Jason A. Donenfeld
@ 2020-11-30 18:34                                       ` Riccardo Paolo Bestetti
  2022-04-22 20:21                                       ` zer0flash
  1 sibling, 0 replies; 39+ messages in thread
From: Riccardo Paolo Bestetti @ 2020-11-30 18:34 UTC (permalink / raw)
  To: Jason A. Donenfeld, Phillip McMahon; +Cc: WireGuard mailing list

On Sun Nov 29, 2020 at 9:59 PM CET, Jason A. Donenfeld wrote:
> Alright. Well, if you do think of good reasons why NCO is not a good
> match for unpriv'd WireGuard control, please let me know. The whole
> basis of going that route is the apparent intuition that these two
> types of things, network modification and tunnel up/down, are one and
> the same. But if you have in mind a way where the analogy breaks down,
I had actually never thought about this specifically before this
discussion, but after deploying v0.3 I realized that network
modification and tunnel up/down are /not/ one and the same!

It makes sense that an employee, or even I when running as a non-admin,
would be able to up/down interfaces; but not create, modify or delete
them. It's the same with software: a standard user cannot install it or
uninstall it, but [s]he can use it.

I think this model really works well. I'm happy with it.

Riccardo


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Probable Heresy ;-)
  2020-11-30 12:47                                   ` Probable Heresy ;-) Peter Whisker
@ 2020-12-02 13:40                                     ` Jason A. Donenfeld
  2021-01-03 11:08                                       ` Christopher Ng
  0 siblings, 1 reply; 39+ messages in thread
From: Jason A. Donenfeld @ 2020-12-02 13:40 UTC (permalink / raw)
  To: Peter Whisker; +Cc: WireGuard mailing list

Seems like you already answered your own inquiry: compression before
encryption has a nasty habit of leaking bits.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Probable Heresy ;-)
  2020-12-02 13:40                                     ` Jason A. Donenfeld
@ 2021-01-03 11:08                                       ` Christopher Ng
  0 siblings, 0 replies; 39+ messages in thread
From: Christopher Ng @ 2021-01-03 11:08 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: Peter Whisker, WireGuard mailing list

bit late to the party on this but OpenVPN themselves recommend you
disable compression.

On Wed, 2 Dec 2020 at 13:40, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Seems like you already answered your own inquiry: compression before
> encryption has a nasty habit of leaking bits.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-29 20:59                                     ` Jason A. Donenfeld
  2020-11-30 18:34                                       ` Riccardo Paolo Bestetti
@ 2022-04-22 20:21                                       ` zer0flash
  1 sibling, 0 replies; 39+ messages in thread
From: zer0flash @ 2022-04-22 20:21 UTC (permalink / raw)
  To: Jason A. Donenfeld, Phillip McMahon
  Cc: Adrian Larsen, Clint Dovholuk, Riccardo Paolo Bestetti,
	WireGuard mailing list

Hi,

On Sun, Nov 29, 2020 at 9:59 PM Jason A. Donenfeld wrote:
> On Sun, Nov 29, 2020 at 8:44 PM Phillip McMahon
> <phillip.mcmahon@gmail.com> wrote:
>> Won't drag this already long and confusing thread out. Not challenging
>> the current implementation, just the notion that any other suggestion
>> is a dead end and the topic is closed.
> 
> Alright. Well, if you do think of good reasons why NCO is not a good
> match for unpriv'd WireGuard control, please let me know. The whole
> basis of going that route is the apparent intuition that these two
> types of things, network modification and tunnel up/down, are one and
> the same. But if you have in mind a way where the analogy breaks down,
> that'd be very interesting to learn and would potentially be grounds
> for changing course.

We provision a lot of road warrior laptops, where users are not admins. 
They can of course use 5g, wifi or lan as required and have to be able 
to switch on/off the vpn tunnel. If working from our office for example, 
they do not need the vpn due to an existing site-to-site vpn connection. 
So they need to turn it off by themselves. That's why the feature makes 
a lot of sense in my humble opinition.

However, any member of the local "Network Configuration Operators" group 
is not only able to to activate the WireGuard tunnel but also

- disable any firewall rules
- add new any firewall rules
- disable the whole firewall by changing the default to allow all incoming
- change ip address / dns settings on any interface

I think that adding an otherwise unprivileged user to the NCO group just 
for activating a preconfigured vpn tunnel might pose security issues in 
other areas.

> 
> Jason
> 

Regards

--
Fabian

^ permalink raw reply	[flat|nested] 39+ messages in thread

* RE: Using WireGuard on Windows as non-admin - proper solution?
       [not found]               ` <8bf9e364f87bd0018dabca03dcc8c19b@mail.gmail.com>
@ 2020-11-25 20:10                 ` Riccardo Paolo Bestetti
  2020-11-25 21:42                 ` Jason A. Donenfeld
  1 sibling, 0 replies; 39+ messages in thread
From: Riccardo Paolo Bestetti @ 2020-11-25 20:10 UTC (permalink / raw)
  To: Clint Dovholuk; +Cc: WireGuard mailing list

On Wed Nov 25, 2020 at 6:57 PM CET, Clint Dovholuk wrote:
> Out of curiosity - why not just use " S-1-5-4" Interactive - " A group
> that
> includes all users that have logged on interactively. Membership is
> controlled by the operating system."
>
> If the user logged on - let the turn the tunnel on/off?
Isn't this akin to having no permissions at all?

Furthermore, I think the point of this feature is to give more
fine-grained control to IT admins. Which it accomplishes, without
introducing much complexity. Piece of beauty!

Riccardo


^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, other threads:[~2022-04-24 20:12 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-12 15:18 Using WireGuard on Windows as non-admin - proper solution? vh217
2020-11-13  2:16 ` Jason A. Donenfeld
2020-11-13 12:03   ` Der PCFreak
2020-11-15 15:28   ` Patrik Holmqvist
2020-11-19 16:56     ` Jason A. Donenfeld
2020-11-20 11:49       ` Patrik Holmqvist
2020-11-20 12:52         ` Jason A. Donenfeld
2020-11-20 13:10           ` Patrick Fogarty
2020-11-20 13:14           ` Patrik Holmqvist
2020-11-17 10:18   ` Viktor H
2020-11-26  7:09   ` Chris Bennett
2020-11-21 10:05 ` Jason A. Donenfeld
2020-11-22 12:55   ` Jason A. Donenfeld
2020-11-23 14:57     ` Fatih USTA
2020-11-24 23:42   ` Riccardo Paolo Bestetti
2020-11-25  1:08     ` Jason A. Donenfeld
2020-11-25  7:49       ` Riccardo Paolo Bestetti
2020-11-25 10:30         ` Jason A. Donenfeld
2020-11-25 11:45           ` Jason A. Donenfeld
2020-11-25 14:08             ` Riccardo Paolo Bestetti
     [not found]               ` <8bf9e364f87bd0018dabca03dcc8c19b@mail.gmail.com>
2020-11-25 20:10                 ` Riccardo Paolo Bestetti
2020-11-25 21:42                 ` Jason A. Donenfeld
2020-11-26  8:53                   ` Adrian Larsen
2020-11-28 14:28                     ` Jason A. Donenfeld
2020-11-29  9:30                       ` Adrian Larsen
2020-11-29 10:52                         ` Jason A. Donenfeld
2020-11-29 12:09                           ` Phillip McMahon
2020-11-29 12:50                             ` Jason A. Donenfeld
2020-11-29 13:40                               ` Phillip McMahon
2020-11-29 17:52                                 ` Jason A. Donenfeld
2020-11-29 19:44                                   ` Phillip McMahon
2020-11-29 20:59                                     ` Jason A. Donenfeld
2020-11-30 18:34                                       ` Riccardo Paolo Bestetti
2022-04-22 20:21                                       ` zer0flash
2020-11-30 12:47                                   ` Probable Heresy ;-) Peter Whisker
2020-12-02 13:40                                     ` Jason A. Donenfeld
2021-01-03 11:08                                       ` Christopher Ng
2020-11-25 12:40     ` AW: Using WireGuard on Windows as non-admin - proper solution? Joachim Lindenberg
2020-11-25 13:08       ` Jason A. Donenfeld

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).