Moving to interactive service

[lstipakov]

As discussed during the last hackathon, we're moving to use interactive service for privileged operations, which will enable us to run openvpn process under limited privileges. Basically instead of starting openvpn process directly, we connect to interactive service as a pipe client and send startup info, same way as gui does.

There are few points to discuss:

• Under what account we should run the service? One idea could be LocalService which is more limited compared to LocalSystem, but we are not the only ones who use it. Maybe the better way would be to create OpenVPNUser without interactive logon rights.
• Whatever user we choose, it should be a member of OpenVPNAdministrators group, because persistent connections often contain "unsafe" options.
• Log folder is defined in HKLM\SOFTWARE\OpenVPN\log_dir. Since C:\Program Files\OpenVPN\log (default value, set by installer) is not writable for unprivileged user, we should change it in installer to something like C:\ProgramData\OpenVPN\log\. Maybe for consistency we should also migrate config-auto there?
• There is a code to check openvpn process exit status and restart it in case of unexpected termination. Since we don't communicate directly with openvpn process, this will not work. Shall we just remove it? Shall we re-implement it in some other way?
• I probably forgot something.

Would be nice to hear your opinions @selvanair @cron2 @d12fk

[selvanair]

There are few points to discuss:

• Under what account we should run the service? One idea could be LocalService which is more limited compared to LocalSystem, but we are not the only ones who use it. Maybe the better way would be to create OpenVPNUser without interactive logon rights.

A custom service account like OpenVPNServiceUser would be better

• Log folder is defined in HKLM\SOFTWARE\OpenVPN\log_dir. Since C:\Program Files\OpenVPN\log (default value, set by installer) is not writable for unprivileged user, we should change it in installer to something like C:\ProgramData\OpenVPN\log\. Maybe for consistency we should also migrate config-auto there?

Moving logs to C:\ProgramData sounds good. Not sure of config-auto as that would leave config locations fragmented with system-wide configs in C:\Program Files\OpenVPN\config\. I'm unsure.

• There is a code to check openvpn process exit status and restart it in case of unexpected termination. Since we don't communicate directly with openvpn process, this will not work. Shall we just remove it? Shall we re-implement it in some other way?

This is the most important function of the service and needs to be retained -- in fact we used to have too many complaints for the old legacy service as that one was unreliable on this front. The service has to remain a watchdog, not something that starts OpenVPN and then forgets about it.

[selvanair]

Getting watchdog work with interactive service was surprisingly [easy]
(ae899ac) - the service returns openvpn process PID via the pipe, and the PID could be hooked up to C# process management code.

That was my feeling, but I was unsure whether a win32 process created by CreateProcess automatically gets an equivalent of "EnableRaisingEvents" set so that "Exited" event can be surbscribed from managed code.

It looks like Windows doesn't allow to run services under passwordless users by default (apart from existing accounts like LocalService), and changing this setting globally looks wrong. We could create a user during installation and give it a random password, but have to be careful that the password won't leak into logs.

Can we use the virtual account feature: i.e set NT SERVICE\<servicename> which is automatically managed? As done by SQL server, for example.

[lstipakov]

Can we use the virtual account feature: i.e set NT SERVICE<servicename> which is automatically managed? As done by SQL server, for example.

Can we impersonate as VSA?

[lstipakov]

Can we impersonate as VSA?

We can!

[selvanair]

Can we impersonate as VSA?
I think so.

[lstipakov]

That was my feeling, but I was unsure whether a win32 process created by CreateProcess automatically gets an equivalent of "EnableRaisingEvents" set so that "Exited" event can be surbscribed from managed code.

Looks like VSA (NT SERVICE\OpenVPNService) doesn't have privileges to do EnableRaisingEvents for another process (even though it is run under the same account). Let me see what can be done (apart from polling).

[d12fk]

* Log folder is defined in `HKLM\SOFTWARE\OpenVPN\log_dir`. Since `C:\Program Files\OpenVPN\log` (default value, set by installer) is not writable for unprivileged user, we should change it in installer to something like `C:\ProgramData\OpenVPN\log\`. Maybe for consistency we should also migrate `config-auto` there?

Can't we just make the service a management client, like the GUI, and have it log to %APPDATA%, or is that only available after login?

[lstipakov]

Can't we just make the service a management client, like the GUI, and have it log to %APPDATA%, or is that only available after login?

We can make it a management client, but %APPDATA% is user specific, and virtual service account doesn't have a local user. OTOH this account could write to C:\ProgramData\OpenVPN so only change required would be to set different registry key in installer (where log path is read).

[lstipakov]

Interactive service change to allow service account use all options: https://gerrit.openvpn.net/c/openvpn/+/906