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; 22+ 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] 22+ 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
                     ` (2 more replies)
  2020-11-21 10:05 ` Jason A. Donenfeld
  1 sibling, 3 replies; 22+ 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] 22+ 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
  2 siblings, 0 replies; 22+ 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] 22+ 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
  2 siblings, 1 reply; 22+ 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] 22+ 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
  2 siblings, 0 replies; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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: " Joachim Lindenberg
  1 sibling, 2 replies; 22+ 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] 22+ 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: " Joachim Lindenberg
  1 sibling, 1 reply; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ messages in thread

* Re: Using WireGuard on Windows as non-admin - proper solution?
  2020-11-25 12:40     ` AW: " Joachim Lindenberg
@ 2020-11-25 13:08       ` Jason A. Donenfeld
  0 siblings, 0 replies; 22+ 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] 22+ 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
  0 siblings, 0 replies; 22+ 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] 22+ 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
  0 siblings, 0 replies; 22+ 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] 22+ messages in thread

end of thread, other threads:[~2020-11-25 20:13 UTC | newest]

Thread overview: 22+ 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-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
2020-11-25 12:40     ` AW: " Joachim Lindenberg
2020-11-25 13:08       ` Jason A. Donenfeld
     [not found] <8bf9e364f87bd0018dabca03dcc8c19b@mail.gmail.com>
2020-11-25 20:10 ` Riccardo Paolo Bestetti

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/wireguard

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 wireguard wireguard/ http://inbox.vuxu.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git