Re: [Openvpn-devel] [DISCUSSION] OpenVPN privilege separation (Windows)

[Alon Bar-Lev]

On Tue, Mar 6, 2012 at 12:34 PM, michael-dev  wrote:
> Hi,
>
> just to give you feedback that your thread is actually followed.

This is great!

> I believe the different types of configuration are good and correct and
> that a good threat analysis is a basic step to proper security, though I
> cannot say much about the isolation tricks on Windows. The important
> think is, as far as I get it, that the network component only changes
> the routes in a trusted way - otherways, there would be no difference in
> either doing this directly or by instrumenting the network component.

Well,
The basic setup is to have it all running under the interactive user.
Assigning the interactive user to the network operators.
Changing the TAP ACL to the network operators.
I think this sufficient to 80% of standalone setups.
BTW: This is fully supported configuration right now.

But, there was a requirement raised in the list to not allow user to
do any privileged operation, but still allowing openvpn to run scripts
on behalf of the user.

This requires splitting the address/dns/routing setup from the
interactive user and/or the user openvpn runs against. Although this
is more complex approach it fits in the least privileged best
practices. So I suggested to do this via COM+, and not manually using
LSA/Named Pipes/services.

This model can be extended with more validations, for example the
OpenVPNUI.Network can validate that only TAP interface is configured,
and that routing are placed only when TAP is destination. So we are
good with least privileged best practices with flexible and generic
approach.

Alon.

>
> Regards,
>  M. Braun
>
> On Wed, 29 Feb 2012 20:52:15 +0200, Alon Bar-Lev wrote:
>> Hello,
>>
>> Following recent discussion on Windows platform, I open a new thread.
>> I don't think this topic is Windows specific as the security
>> principals are the same.
>>
>> VPN client product has [at least] two different type of
>> configuration.
>>
>> 1. Standalone configuration.
>>
>> 2. Enterprise configuration.
>>
>> The main difference of these types is who control the workstation. In
>> standalone configuration the workstation is controlled by the
>> end-user, and in enterprise configuration the enterprise
>> administrator
>> controlling the workstation.
>>
>> These two configurations have different purpose as well, the
>> standalone configuration usually protects the workstation against the
>> remote network, and the enterprise configuration usually protects the
>> remote network against the workstation.
>>
>> The "enemy" of the two configurations is also different, in
>> standalone
>> configuration the "enemy" is the remote network administrator, while
>> in the enterprise configuration the "enemy" is the local workstation
>> user.
>>
>> The "scripts" in the standalone configuration or for the sake of the
>> user, but within the enterprise solution it usually need to scan the
>> computer, disconnect device and other privileged operations.
>>
>> There is no single solution for both configurations.
>>
>> Please read till the end before responding.
>>
>> Provided we have the following components:
>> 1. tap device aka tap - a virtual Ethernet interface.
>> 2. openvpn - a tunneling implementation.
>> 3. openvpn configuration - configuration files.
>> 3. network utilities aka utils - a set of utilities to manipulate
>> workstation network settings.
>> 4. user interaction aka UI - a program that manages user interaction.
>>
>> What is the security attribute for each component in each
>> configuration?
>>
>> Standalone configuration
>> 1. tap - accessed by interactive user.
>> 2. openvpn - runs by the interactive user.
>> 3. openvpn configuration - read/write by interactive user.
>> 4. network utilities - privileged user required.
>> 5. UI - runs by interactive user.
>>
>> Enterprise configuration
>> 1. tap - access by openvpn user.
>> 2. openvpn - runs by openvpn user.
>> 3. openvpn configuration - read by openvpn, read/write by
>> administrator.
>> 4. network utilities - privileged user required.
>> 5. UI - runs by interactive user.
>>
>> Major missing openvpn functionality:
>> Specify certificate via the management UI - this feature is required
>> so that a configuration in which openvpn knows nothing of
>> authentication can be established.
>>
>> A while back I added to openvpn the ability to create tun/tap device
>> with custom permissions
>> and the ability to wrap ip utility with custom utility.
>> As for now I am using the standalone Linux configuration[1], in few
>> words:
>> 1. tap is configured so interactive user may access it.
>> 2. openvpn is run by the interactive user.
>> 3. openvpn configuration and keys are located at ~/openvpn
>> 4. network utilities - (ip utility and DNS update) are wrapped within
>> sudo scripts.
>> 5. UI is run by the interactive user.
>>
>> The network utilities' wrapper can do validation before actually
>> executing the commands.
>>
>> There is no reason why 

Re: [Openvpn-devel] [DISCUSSION] OpenVPN privilege separation (Windows)

[michael-dev]

Hi,

just to give you feedback that your thread is actually followed.
I believe the different types of configuration are good and correct and 
that a good threat analysis is a basic step to proper security, though I 
cannot say much about the isolation tricks on Windows. The important 
think is, as far as I get it, that the network component only changes 
the routes in a trusted way - otherways, there would be no difference in 
either doing this directly or by instrumenting the network component.


Regards,
 M. Braun

On Wed, 29 Feb 2012 20:52:15 +0200, Alon Bar-Lev wrote:

Hello,

Following recent discussion on Windows platform, I open a new thread.
I don't think this topic is Windows specific as the security
principals are the same.

VPN client product has [at least] two different type of 
configuration.


1. Standalone configuration.

2. Enterprise configuration.

The main difference of these types is who control the workstation. In
standalone configuration the workstation is controlled by the
end-user, and in enterprise configuration the enterprise 
administrator

controlling the workstation.

These two configurations have different purpose as well, the
standalone configuration usually protects the workstation against the
remote network, and the enterprise configuration usually protects the
remote network against the workstation.

The "enemy" of the two configurations is also different, in 
standalone

configuration the "enemy" is the remote network administrator, while
in the enterprise configuration the "enemy" is the local workstation
user.

The "scripts" in the standalone configuration or for the sake of the
user, but within the enterprise solution it usually need to scan the
computer, disconnect device and other privileged operations.

There is no single solution for both configurations.

Please read till the end before responding.

Provided we have the following components:
1. tap device aka tap - a virtual Ethernet interface.
2. openvpn - a tunneling implementation.
3. openvpn configuration - configuration files.
3. network utilities aka utils - a set of utilities to manipulate
workstation network settings.
4. user interaction aka UI - a program that manages user interaction.

What is the security attribute for each component in each 
configuration?


Standalone configuration
1. tap - accessed by interactive user.
2. openvpn - runs by the interactive user.
3. openvpn configuration - read/write by interactive user.
4. network utilities - privileged user required.
5. UI - runs by interactive user.

Enterprise configuration
1. tap - access by openvpn user.
2. openvpn - runs by openvpn user.
3. openvpn configuration - read by openvpn, read/write by 
administrator.

4. network utilities - privileged user required.
5. UI - runs by interactive user.

Major missing openvpn functionality:
Specify certificate via the management UI - this feature is required
so that a configuration in which openvpn knows nothing of
authentication can be established.

A while back I added to openvpn the ability to create tun/tap device
with custom permissions
and the ability to wrap ip utility with custom utility.
As for now I am using the standalone Linux configuration[1], in few 
words:

1. tap is configured so interactive user may access it.
2. openvpn is run by the interactive user.
3. openvpn configuration and keys are located at ~/openvpn
4. network utilities - (ip utility and DNS update) are wrapped within
sudo scripts.
5. UI is run by the interactive user.

The network utilities' wrapper can do validation before actually
executing the commands.

There is no reason why we cannot achieve the same in Windows:
1. tap - configure ACL of TAP to specific permissions (Users for 
example).

2. openvpn - runs by the interactive user, it will have permission to
open the tap.
3. openvpn configuration - read/write by interactive user.
4. network utilities are accessed by wrapper (I will discuss this 
bellow).

5. UI is run by the interactive user.

So the network utilities are the only component that needs privilege
escalation in this configuration.

Let's take the enterprise configuration:
1. tap - configure ACL of TAP to openvpn user.
2. openvpn - runs by openvpn user.
3. openvpn configuration - read by openvpn, read/write by 
administrator.
4. network utilities are accessed by wrapper (I will discuss this 
bellow).

5. UI runs by the interactive user.

So in this case, network utilities needs privilege escalation, but
also the ability of the UI to start/stop the tunnel requires special
privilege.

I gave an example of how this is done in Linux... Now, what is the
simplest solution to do the same in Windows?

There was a suggestion to use named pipes, services and 
impersonation,

I would like to discuss another option.

Windows Component Services provide the ability to create a component
that may be run in separate security context. It already implements
the process management and security isolation.

Let's define two 

Re: [Openvpn-devel] [DISCUSSION] OpenVPN privilege separation (Windows)

[Alon Bar-Lev]

OK,
I will continue to discuss this with my-self, as apparently what I am
showing is not significant enough to have a proper technical
discussion. There is nothing wrong in open mind to other
possibilities, evaluate and with rational select the best approach.

For the lazy people of us, I added installation script[1] to do all
the steps automatically.

Compile the project, move the install.js, test.js,
OpenVPNUINetwork.dll, OpenVPNUITunnel.dll to some directory.

> cscript //nologo install.js --command=install --mode=enterprise
-- Add your user to OpenVPN Users group logout/login

> cscript //nologo test.js
> cscript //nologo install.js --command=update --mode=standalone
> cscript //nologo test.js
> cscript //nologo install.js --command=update --mode=enterprise
> cscript //nologo test.js

> cscript //nologo install.js --command=uninstall

BTW: For these who are not familiar with ATL programming, most of the
code is generated by the Microsoft wizards, the actual added code
resides in Network.cpp and Tunnel.cpp files.

Alon.

[1] 
https://github.com/alonbl/openvpn-gui-skeleton/blob/master/scripts/install.js

On Fri, Mar 2, 2012 at 1:20 AM, Alon Bar-Lev  wrote:
> Hello Again,
>
> To make it easier to understand and help to demonstrate the
> technology, I created skeleton[1] for the alternative I suggested.
>
> It uses the COM+ infrastructure to achieve what we need avoiding
> complex programming.
>
> We have two COM+ objects:
> OpenVPNUI.Network - runs under user belongs to the network
> configuration operators group.
> OpenVPNUI.Tunnel - runs under unprivileged user.
>
> We control the identity and access to these object using the COM+
> infrastructure. COM+ does all the work for us, we don't need to do
> communication or security check within code.
>
> The manual configuration is quite long, I wrote step-by-step, it is
> good for people who wish to understand what happening. There is more
> configuration than actual coding which is great.
>
> The script/test.js script is used to test this infrastructure.
>
> Use the setup instructions bellow, you will get the most secured
> configuration, total privilege separation. OpenVPN daemon which will
> be run by the OpenVPNUI.Tunnel object runs under its own unprivileged
> account and only this account can access the OpenVPNUI.Network object
> which is within the network operators group. As a result the
> interactive user cannot change routes or hack into the OpenVPN daemon
> address space. Of course that in this configuration only Administrator
> is allowed to modify the configuration files, to not allowing the user
> to execute own script under the openvpn context. In this case the UI
> it-self should execute user specific connect/disconnect scripts, it
> receives these events, no reason why the daemon needs to do so. But be
> patient, I will show how it can be done if desired.
>
> The output of the script in this configuration is:
> ---
> Trying to access OpenVPNUI.Network directly
> Creating OpenVPNUI.Network
> ERROR: Permission denied
>
>
> Trying to access OpenVPNUI.Tunnel
> Creating OpenVPNUI.Tunnel
> OpenVPNTunnel identity is: openvpn
> Creating Route for 1.0.0.0
> ==
> Active Routes:
> Network Destination        Netmask          Gateway       Interface  Metric
>          0.0.0.0          0.0.0.0    192.168.151.1  192.168.151.10       1
>          1.0.0.0          1.0.0.0          2.0.0.0  192.168.151.10      1
>        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
> 
> Default Gateway:     192.168.151.1
> ==
>
>
> Deleting Route for 1.0.0.0
> ==
> Active Routes:
> Network Destination        Netmask          Gateway       Interface  Metric
>          0.0.0.0          0.0.0.0    192.168.151.1  192.168.151.10       1
>        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
> 
> Default Gateway:     192.168.151.1
> ==
>
> ---
>
> So what do we see here?
> My interactive user cannot access the  OpenVPNUI.Network object, but
> can access the  OpenVPNUI.Tunnel. The user of the OpenVPNUI.Network
> object is openvpn, this user can access the  OpenVPNUI.Network object,
> so the it can modify the route.
>
> Now, let's change the permissions the the standalone configuration,
> meaning the interactive user can modify the openvpn configuration, and
> we may want openvpn to run under the interactive user account to
> execute some scripts.
>
> Before we do this, I would like to say that I disagree with the fact
> that "connect/disconnect" scripts should be run by the daemon, I think
> that these scripts should be run by the UI it-self that is already run
> under the interactive user. No *NEW* security issue issue will be
> created if user is allowed to change configuration but daemon runs
> under the openvpn unprivileged account.
>
> Anyway, as this was discussed as an option, lets do the