RFD 195: Windows VNet Support #50850
Conversation
| When calling the `AuthenticateProcess` RPC, the Windows service will: | ||
| 1. Create a Windows named pipe and give the installing user SID permission to open the pipe. | ||
| 1. Pass the name of the pipe (via the RPC) to the user process. | ||
| 1. Wait for the user process to dial the named pipe. | ||
| 1. Use the Windows API `GetNamedPipeClientProcessId` to get the pipe client | ||
| process handle. | ||
| 1. Once it has the user process handle, it can confirm the path of the exe | ||
| matches the path of the Windows service, and confirm that the exe is signed | ||
| by the same issuer as itself. |
There was a problem hiding this comment.
What happens if this fails for some reason? What is the UX for the user?
nklaassen
force-pushed
the
rfd/0195-vnet-windows
branch
from
aa25e62 to
2b4ce36
Compare
nklaassen
added
the
no-changelog
|
TODO: when installing the windows service, the exe for the service is identified by a filesystem path to the exe, and every time the service starts it will execute that exe. if any user can overwrite the exe at that path, they could run their own exe as a service, with admin rights, and they would be allowed to start the service without admin rights in the current design. To prevent this we need to install the tsh exe in a path that cannot be written without admin rights, probably under "Program Files". Currently the electron installer installs everything under C:\Users<user>\AppData, which the user can always overwrite, so this is a problem. Perhaps when we install the service we can copy the tsh exe to "Program Files" and use that path for the service. Need to consider conflicts if the user installs both Connect and standalone tsh, and if they can share this path |
No description provided.