Hi
On Tue, Dec 17, 2019 at 6:09 AM Simon Rozman wrote:
>
> I have been playing with Lev's patches for the past few days. Tested them,
> debugged them, did some fixes. There are things to be desired like
> netsh=>ipcfg, remove or #ifdef the SYSTEM token hack... But those are design
> choices
Hi Simon,
A quick reply:
> > IMO, the right approach on Windows is to run a bare minimal code as a
> > service to get SYSTEM rights and the rest with limited privileges.
>
> Selva, those are two different use-cases. And none is "right" or "wrong".
> OpenVPN can or should have both. :)
>
> 1. I
nvpn-devel
Subject: Re: [Openvpn-devel] [PATCH v6 4/7] wintun: ring buffers based I/O
How about compromise - let's add "--enable-system-elevation" windows specific
option.
- When it is set, we print warning and elevate to SYSTEM for the single
DeviceIOControl call
- When it i
Hi,
> > I am running OpenVPN on Windows using NSSM wrapper for years. I had a
> brief discussion on the Hackathon with Samuli about integrating SCM
> support directly into openvpn.exe (imagine --daemon for Windows):
> >
> > sc create OpenVPN$MyTunnel binpath= "C:\Program
> >
How about compromise - let's add "--enable-system-elevation" windows
specific option.
- When it is set, we print warning and elevate to SYSTEM for the single
DeviceIOControl call
- When it is not set and wintun is used, we run openvpn from command line
via iservice
- If service is missing,
Hi
On Mon, Dec 16, 2019 at 4:31 PM Lev Stipakov wrote:
>>
>> I have already said what I think of it. As an admin I wouldn't like to see
>> users running processes that elevate to SYSTEM like this.
>
>
> Would it be too much if
>
> - openvpn.exe process detects that it is not started by
Hi,
>>> TLDR:
>>> (i) stealing SYSTEM access from winlogon.exe is not a good thing to do
>>
>>
>> This doesn't happen for the majority of use cases - only when iservice is
>> not used. We also
>> elevate only for the single DeviceIOControl call.
>
> I understand. But stealing access token
>
> I have already said what I think of it. As an admin I wouldn't like to see
> users running processes that elevate to SYSTEM like this.
>
Would it be too much if
- openvpn.exe process detects that it is not started by interactive service
- interactive service process is running
- wintun is
Hi
On Mon, Dec 16, 2019 at 3:01 PM Lev Stipakov wrote:
>
> Hi,
>
> Thanks for looking into this. See my comments below.
>
>> TLDR:
>> (i) stealing SYSTEM access from winlogon.exe is not a good thing to do
>
>
> This doesn't happen for the majority of use cases - only when iservice is not
>
Hi,
Thanks for looking into this. See my comments below.
TLDR:
> (i) stealing SYSTEM access from winlogon.exe is not a good thing to do
>
This doesn't happen for the majority of use cases - only when iservice is
not used. We also
elevate only for the single DeviceIOControl call.
Below you
Hi,
I was reluctant to review this as I do not understand
the event processing in OpenVPN well enough. Now that Stefann
has reviewed those bits and given an Ack, here are some
comments on the rest of the code.
TLDR:
(i) stealing SYSTEM access from winlogon.exe is not a good thing to do
(ii) with
Hi Lev,
Thanks for the update. Even with the latest added fixes and sanity
checks, the resulting code is now 30 lines shorter *and* more readable.
Some last questions / comments inline:
On 13-12-2019 20:19, Lev Stipakov wrote:
> @@ -2099,6 +2115,13 @@ io_wait_dowork(struct context *c, const
From: Lev Stipakov
Implemented according to Wintun documentation
and reference client code.
Wintun uses ring buffers to communicate between
kernel driver and user process. Client allocates
send and receive ring buffers, creates events
and passes it to kernel driver under LocalSystem
privileges.
13 matches
Mail list logo
