2018-05-23 14:06 GMT+05:00 David Sommerseth <
open...@sf.lists.topphemmelig.net>:
> On 23/05/18 10:08, Илья Шипицин wrote:
> > Hello,
> >
> > we observe weird registry corruption, when "exe_path" points to wrong
> location.
> > I came to an idea, why not to link both service and openvpn.exe into
> single
> > openvpn.exe thus removing the need to specify exe_path at all ?
> >
> > thoughts ?
>
> Why not just use dirname() of the openvpn.exe binary path and expect the
> service to stay in the same directory?
>
we agreed with Selva Nair to use dirname() as the last resort when registry
is missing.
(I haven't send patch yet)
however, what I talk about is a different case. "exe_path" exists, but it
points to wrong location.
>
> Linking openvpn.exe and the interactive service is not going to be a
> trivial
> task at all and will mandate two different main() functions which are
> triggered depending on either basename(argv[0]) or some options ... this is
> going to be messy.
>
> Plus this approach can more open up new attack vectors as well, as a single
> binary can do much more work. Like a buffer overflow in the packet
> processing
> (UDP/TCP or TUN/TAP code paths) triggering execution of interactive service
> functions - this can easily be abused for privilege separation as the
> interactive service runs with elevated privileges while the plain openvpn
> side
> runs unprivileged now.
>
> So no, we should not "link" the interactive service with openvpn.exe. Even
> though I am no big fan of qmail and the ucspi-tcp package, there are a few
> key
> things to learn from that approach. Each individual piece in the qmail
> chain
> does a very limited set of tasks and focuses only on that. So if there's a
> exploit happening in one of the pieces in the chain, the damage is quite
> controlled and limited to the privileges of that individual piece. It can
> truly be a big hassle and pain to set up such an environment, but it has
> some
> merits regardless. I do not say we should split up OpenVPN like qmail,
> but we
> should try to keep the footprint privileged code running as small and
> controlled as possible. Which is why we have interactive service and why
> we're working on a NETLINK integration on Linux. And OpenVPN 3 on Linux
> takes
> a very different approach to this as well, and there is work in the pipe to
> reduce the privileged footprint even further.
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Inc
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
