* 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-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-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-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-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
* 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
[parent not found: <8bf9e364f87bd0018dabca03dcc8c19b@mail.gmail.com>]
* 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
* 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-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
* 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: 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
* 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: 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
* 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
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).