Re: [Openvpn-devel] OpenVPN 2.3-alpha1 / GUI

[Gert Doering]

Hi,

On Thu, Mar 01, 2012 at 10:11:23AM +0100, Heiko Hund wrote:
> UL/DL stats added to the tool tip of the tray icon however is easy 
> to implement and interesting enough to anyone that I like it immediately.

Blinkenlight good!

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpaAJKubxSpg.pgp
Description: PGP signature

Re: [Openvpn-devel] Project management and direction (WAS: Re: OpenVPN 2.3-alpha1 released)

[Samuli Seppänen]

Il 01.03.2012 14:49, Alon Bar-Lev ha scritto:
> On Thu, Mar 1, 2012 at 12:41 PM, Samuli Seppänen  wrote:
>> 1) Preliminary topic list is sent to openvpn-devel ml
>> 2) The actual meeting (fully open)
>> 3) The meeting summary + complete chatlog is sent to openvpn-devel ml
>>
>> The idea was to minimize the negative impact of the meetings as much as
>> possible. Also, we haven't had that many meetings in a long while:
>>
>> 
>>
>> The dangerous aspect of the IRC is it's more personal nature, and the
>> fact that it's far quicker to get feedback from there than from the
>> mailing list. The problem is that only a subset of developers and
>> community members hang out on the IRC. This is fine, as long as the
>> people on the mailing lists are not excluded from the discussion. This
>> is where we need to be really careful and not get too comfortable on the
>> IRC channel.
> The problem is with the "Meeting Summary"... It breaks the discussion.
> Let's say you have discussion on topic , this thread has 10 messages.
> Then there is a "Meeting Summary" where  is discussed.
> Then you continue to discuss the  as reply to the "Meeting
> Summary" or in entirely different thread.
> As a result you may loose the people discussing .
> And you lose the history of discussion , as you need to go and
> look in many threads and instances.
>
> If IRC tool is used, it should be used as a proxy. Each summary should
> be replied to the designated thread to allow proper asynchronous
> communication without breaking the sequence because of a synchronous
> meeting.
>
> If James has problems with reading mails, you can discuss with him any
> subject but again reply to the appropriate thread to avoid breaking
> the sequence.
>
> Reading IRC logs is way out of valid request...
>
> Just my two cents.
>
> Alon.
I think we've done this to some extent already byreplying with "this
topic was discussed in the IRC meeting" when appropriate. In principle
this makes sense, although I'm not sure if all meeting topics are
suitable for this approach, i.e. are worth a full email.

Let's think about this the next time we actually _do_ have a meeting :).

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] Project management and direction (WAS: Re: OpenVPN 2.3-alpha1 released)

[Carsten Krüger]

Hello Alon,

ABL> The problem is with the "Meeting Summary"... It breaks the discussion.

ACK but you can't prohibit out of bound communication.

ABL> Reading IRC logs is way out of valid request...

ACK

It would be nice if there proper responses on the list.

greetings
CArsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello David,

Thx for explantion of script usage.

DS> Well, I can agree to that.  But this is all open source.  No matter how
DS> much restrictions you put into the openvpn product, the user can download
DS> the source, add the features missing, and reconnect with a modified
DS> OpenVPN version.

ACK, if he has the complete configuration and all secrets.

But in enterprise scenario the user has only a company configured
machine and his own username/password or smartcard. For example
tls-key could be unkown to user.
The user can't boot his own machine, install patched openvpn and
connect to vpn server because one secret is missing.

That's the reason why I think openvpn shouldn't be started as an user
and config must controlled from enterprise.

Cisco introduced a stupid encryption of key material in .vcf.
The user should be allowed to setup the tunnel on this own.
User can take http://newgre.net/passwordrevealer and Shrewsoft Client
to connect. All enforcements are gone (push redirect-gateway for
example).

DS> be code which is not easily available, so the client can't fake this
DS> operation as well.

ACK

DS> Bottom line is, you can't fully control the client environment.

You can't control the client from a VPN tool. You have to control the
client in enterprise directly. Group policies, software restriction
policies, good ACLs, etc.

DS> What you can do on the client side, is to avoid a third party (think
DS> virus/malware) to figure out that openvpn is installed, and tweak the
DS> config to run code which was not supposed to be run with higher
DS> privileges.

Virus runs with user privileges, config is only modifiable with admin
privileges. No problem. Virus can establish VPN connection, same like
the user.

DS>  So the client should try to lock down things locally, to
DS> reduce the impact from local exploits.

Not the openvpn client but the complete machine.

DS> There's no real way you can make the server enforce restrictions on the 
client.

Full ACK

greetings
Carsten

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

[Alon Bar-Lev]

Sending this again, as it seems people did not receive it.


-- Forwarded message --
From: Alon Bar-Lev 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Wed, Feb 29, 2012 at 8:52 PM
Subject: [DISCUSSION] OpenVPN privilege separation (Windows)
To: "openvpn-devel@lists.sourceforge.net" 


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 components:
1. OpenVPN.Tunnel component (replaces current service).
2. OpenVPN.Network component (aka network utilities wrapper).

Now, let's see what we can do with these components.

Standalone configuration
1. TAP ACL - Group Users can 

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/03/12 13:15, Carsten Krüger wrote:
> Hello David,
> 
>> a) Mounting and un-mounting networked filesystems after the tunnel
>> is up. Here I even implemented the --route-pre-down script hook, to
>> unmount the filesystem before the tunnel is taken down.  Here's the
>> config extract:
> 
> This need root rights?

Not necessarily, if /etc/fstab is configured with 'user' you don't need
root priv.  Or if you use FUSE stuff, that often don't need root access
either.  Of course, it all depends on what kind of file system you mount.

>> This client has a web server behind it which is available on the
>> public internet via the openvpn server which got the public IP
>> address.  To make sure the incoming public traffic is returned via
>> the VPN tunnel and not the default gateway on the openvpn client,
>> simple ip rules like the ones below are used in the route-up.sh
> 
>> /sbin/ip rule add from ${ifconfig_local} table 132 /sbin/ip route
>> add default via 10.8.0.1 table 132
> 
>> And the route-down.sh takes care of deleting the rule.  This is to
>> avoid errors and duplications if openvpn is restarted.  (And there
>> are probably other ways to solve this as well, but this is one way)
> 
> Need root rights, too?

This case needs root access, correct.  But this can be tweaked around
using sudo trikcs or similar stuff.  And using SELinux, you can also lock
down things even more.

> Maybe it's a good idea to have two type of scripts. One that is
> controlled from the administrator and is executed with admin/root
> privileges and the other that runs as the user.
> 
>> Plugins can be used on both server side and client side.  They can
>> be used to extend the logging, or do other more advanced things
>> which is easier and cleaner solved in a C program than using plenty
>> of scripts.
> 
> In an enterprise setup I would think a plugin should be not modifable
> by the user (i.e. the user should have no chance to load own
> modules).

Well, I can agree to that.  But this is all open source.  No matter how
much restrictions you put into the openvpn product, the user can download
the source, add the features missing, and reconnect with a modified
OpenVPN version.

Even introducing signatures and hashes which the server evaluates will
not solve this, as the openvpn client can be modified to return exactly
the data the server would expect.

To avoid this, you would need to run some code from the server - which
evaluates the system and reports back to the server.  Then the server can
decide to open up the firewall on the server side or not.  Otherwise, you
have no way to trust the client side at all.  And all this would have to
be code which is not easily available, so the client can't fake this
operation as well.

Bottom line is, you can't fully control the client environment.  All
enforcements needs to happen on the server side.

What you can do on the client side, is to avoid a third party (think
virus/malware) to figure out that openvpn is installed, and tweak the
config to run code which was not supposed to be run with higher
privileges.  So the client should try to lock down things locally, to
reduce the impact from local exploits.  The server side should restrict
the server side, and what is being passed via the tunnel.  There's no
real way you can make the server enforce restrictions on the client.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9PbIIACgkQDC186MBRfrp7GgCdE9FyhidxVP+xYDzZhvbBw6w1
ps0AmwRBWDSHk2MILKfUlrYr5OcuAkbY
=2DnA
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello David,

> a) Mounting and un-mounting networked filesystems after the tunnel is up.
> Here I even implemented the --route-pre-down script hook, to unmount the
> filesystem before the tunnel is taken down.  Here's the config extract:

This need root rights?

> This client has a web server behind it which is available on the public
> internet via the openvpn server which got the public IP address.  To make
> sure the incoming public traffic is returned via the VPN tunnel and not
> the default gateway on the openvpn client, simple ip rules like the ones
> below are used in the route-up.sh

>   /sbin/ip rule add from ${ifconfig_local} table 132
>   /sbin/ip route add default via 10.8.0.1 table 132

> And the route-down.sh takes care of deleting the rule.  This is to avoid
> errors and duplications if openvpn is restarted.  (And there are probably
> other ways to solve this as well, but this is one way)

Need root rights, too?

Maybe it's a good idea to have two type of scripts.
One that is controlled from the administrator and is executed with
admin/root privileges and the other that runs as the user.

> Plugins can be used on both server side and client side.  They can be
> used to extend the logging, or do other more advanced things which is
> easier and cleaner solved in a C program than using plenty of scripts.

In an enterprise setup I would think a plugin should be not modifable by the 
user (i.e. the
user should have no chance to load own modules).

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Heiko Hund]

On Thursday 01 March 2012 11:59:11 Carsten Krüger wrote:
> No. If you start a process in users context the user can modify it.
> There is nothing you could do against.

I'll do some tests next week and post my findings here.

Heiko
-- 
Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
 
Represented by the General Partner Astaro Verwaltungs GmbH
Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany 
Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 29/02/12 20:37, Carsten Krüger wrote:
> Hello,
> 
>> How will you handle that some users use OpenVPN from Windows, Linux
>> and maybe even a mobile phone (like N900)? ... where paths are
>> different, depending on OS and/or distribution.  And some paths on
>> Linux (probably *BSD too?) are different if it is a 32bit
>> architecture or 64bit.
> 
> Do have an example for an script? I've no idea what's the exact
> purpose is, I've never used scripts in openvpn.

I use scripts in a couple of setups.

a) Mounting and un-mounting networked filesystems after the tunnel is up.
Here I even implemented the --route-pre-down script hook, to unmount the
filesystem before the tunnel is taken down.  Here's the config extract:

  script-security 2
  route-up mount.sh
  route-pre-down umount.sh

The mount.sh and umount.sh scripts takes care mounting the right
filesystems.  The umount.sh also waits until it's the filesystem is
really unmounted.


b) Setting up tunnel specific iproute2 rules

   route-up /etc/openvpn/route-up.sh
   plugin /usr/share/openvpn/plugin/lib/openvpn-down-root.so
/etc/openvpn/route-down.sh

This client has a web server behind it which is available on the public
internet via the openvpn server which got the public IP address.  To make
sure the incoming public traffic is returned via the VPN tunnel and not
the default gateway on the openvpn client, simple ip rules like the ones
below are used in the route-up.sh

  /sbin/ip rule add from ${ifconfig_local} table 132
  /sbin/ip route add default via 10.8.0.1 table 132

And the route-down.sh takes care of deleting the rule.  This is to avoid
errors and duplications if openvpn is restarted.  (And there are probably
other ways to solve this as well, but this is one way)

c) Setting up /etc/resolv.conf based on pushed DNS settings
Using the --up script hook, you can extract the DNS server and domain
parameters pushed by the server to update /etc/resolv.conf.

>> And you would also need to go even further, to also make --plugin
>> only pushable too.  Which makes the /usr/lib vs /usr/lib64 scenario
>> a real pain for sure.
> 
> Why do u want to secure openvpn if there is an option for a user to 
> inject plugins? The plugin code do anything.
> 
> Are plugins used only on server side or on clientside, too?

Plugins can be used on both server side and client side.  They can be
used to extend the logging, or do other more advanced things which is
easier and cleaner solved in a C program than using plenty of scripts.

The most common client-side usage of the plug-in is openvpn-down-root.so,
commonly used in the *nix world.  This forks out a process with root
privileges to restore some settings when the tunnel is taken down.
However, this is only needed if --user, --group and/or --chroot options
are used.  See the example b) above.

But I'm not saying that this is the best way to do this.  I'm just saying
this is how such issues are easily solved with today's implementation.

The whole DNS/resolv.conf issue is not present in Windows, because
Windows have no concept of TUN devices.  The TUN/TAP driver in Windows is
a TAP driver which fakes the TUN feature.  So when the TAP device gets
into "initialising mode", Windows makes the device send DHCP requests.
The TAP driver and OpenVPN client then fakes a DHCP server which sends
the IP address together with the DNS resolver info as DHCP packets back
to Windows via the TAP device.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9PZnIACgkQDC186MBRfrrynwCdFuOc4cXf+VsA2ySoM21Bikwr
FSkAn0EH+sRlBLBIjeD11SG0nIqxHn78
=gmKz
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello Heiko,

> Did you try it?

No but I understand the concept of security levels in Windows.
A user can spawn a process with his rights or with lower rights.

>  The service should have sufficient rights to modify it I guess.

No. If you start a process in users context the user can modify it.
There is nothing you could do against.

>> b) dll injection is ONE example of how a user can manipulate his own
>> process. I'm no expert at hacking windows but you can trust me, it
>> exists 1001 possibilities to do the same. You have no chance to block
>> them.

> I file that under FUD until you're more explicit.

I would propose you ask somebody in your company that is experienced
in hacking of windows (maybe someone of the antivir team?)
If a process runs within my security context I can modify it arbitrarily.
That's a very basic concept in operating systems.

I showed you one example how to break your design - injecting a dll.
I'm no expert in hacking processes in windows but from OS design there
have to exists plenty of other ways.

To gave you some ideas, study process hacker.
Try what you could do with your own processes (disable kernel hacker,
otherwise you have full kernel privileges)
http://processhacker.sourceforge.net/
Take a non-admin user, start notepad, start process hacker, go to
properties, view permissions. You could see that on your own process
you have "full control", for example "create thread", "write memory".

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Heiko Hund]

On Thursday 01 March 2012 10:40:51 Carsten Krüger wrote:
> >  If that works out, all that is needed is the service increasing the
> >  tokens integrity> 
> > level before starting openvpn and the user will have limited access to the
> > running openvpn process.
> 
> a) this didn't work, you can lower the level and but not higher

Did you try it? I hope that it doesn't work for a normal user. The service 
should have sufficient rights to modify it I guess. Again these are only 
assumptions. If you have practical experience please be more verbose.

> b) dll injection is ONE example of how a user can manipulate his own
> process. I'm no expert at hacking windows but you can trust me, it
> exists 1001 possibilities to do the same. You have no chance to block
> them.

I file that under FUD until you're more explicit.

Heiko
-- 
Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
 
Represented by the General Partner Astaro Verwaltungs GmbH
Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany 
Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen

[Openvpn-devel] Project management and direction (WAS: Re: OpenVPN 2.3-alpha1 released)

[Samuli Seppänen]

Changing the topic line to something more descriptive. Hope nobody minds.
>>> I only recommend the OpenVPN project manager to hold with this solution,
>>> and manage a proper design process, there are people here who can help, if
>>> the process is managed correctly.
>> Alon, there is a process. It's just different from what you imagine it to be.
>> If you're not keen to get on IRC then read the chat log that gets posted here
>> the next day and comment on it. Comment and counter-propose on patches - as
>> you do - and this project will go forward.
> I disagree, open source project is not different than any other
> software project.
> when you reach to the point of writing code (hence patches), it is way
> too late to
> discuss requirements and design. And the emotional impact of rejecting people
> work at this stage is huge, especially when these involves in great effort.
I agree. That said, the same applies to the buildsystem work you did:
the requirements were vague and there was a lack of design discussion.
Therefore the emotional impact on other developers was identical.

So, in the future, we all should put our major new ideas on the table
(=this mailing list) to

a) figure out the requirements
b) discuss design

After this we can move on to the implementation more safely, without
excluding anyone. I think the early negative comments on some of your
buildsystem patches were indirectly caused by lack of a) and b). Or, in
other words, other developers did not see the big picture because it had
not been presented to them clearly.

Of course, there are occasions when this consensus-process gets us
nowhere due to arguing. In those cases  somebody just needs to move on
to implementation to prove the design. This should not happen often, and
never without a) and b).

> Also please keep in mind we are not being payed for openvpn, nor payed to keep
> project alive, we donate our time and our experience.
>
> If you force people to follow meetings, you may lose experience of people who
> might be busy at that specific time in their day work.
I also much prefer the mailing list for this reason. The original reason
for the IRC meetings was James: he simply didn't have time to read the
emails on openvpn-devel and we needed his advise on some things. The
problem with timezones and people not being able to attend was known
from the beginning, though. That's why the meetings had a specific process:

1) Preliminary topic list is sent to openvpn-devel ml
2) The actual meeting (fully open)
3) The meeting summary + complete chatlog is sent to openvpn-devel ml

The idea was to minimize the negative impact of the meetings as much as
possible. Also, we haven't had that many meetings in a long while:



The dangerous aspect of the IRC is it's more personal nature, and the
fact that it's far quicker to get feedback from there than from the
mailing list. The problem is that only a subset of developers and
community members hang out on the IRC. This is fine, as long as the
people on the mailing lists are not excluded from the discussion. This
is where we need to be really careful and not get too comfortable on the
IRC channel.
> Because of this a proper roadmap and design of significant changes should be
> published and discussed over time, leveraging the overall experience of the
> community.
Very good point, again I agree.

>
> Anyway, I am not managing this project, it is up to him to decide how
> to progress.
And the decisions should be made so that as few people are excluded as
possible.

>
> However, OpenVPN is already very fat monolithic implementation that grow over
> time with a lot of niche features, the code is so complex and
> conditional that it
> is almost impossible to maintain. It is about time to setup up a direction, 
> and
> maybe work toward modular approach first, solving the Windows major issues 
> with
> as minimal effort as possible for the time being.
This is probably long overdue, just as the buildsystem overhaul was.
Some plans for OpenVPN 3.0 were made a while ago:



We should probably reopen this discussion once 2.3 (final) is out.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello Heiko,

>  If that works out, all that is needed is the service increasing the tokens 
> integrity
> level before starting openvpn and the user will have limited access to the
> running openvpn process.

a) this didn't work, you can lower the level and but not higher
b) dll injection is ONE example of how a user can manipulate his own
process. I'm no expert at hacking windows but you can trust me, it
exists 1001 possibilities to do the same. You have no chance to block
them.

Please drop openvpn-service starts openvpn in the context of the user.
It brings in much complexty for no benefit.

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello Gert,

>> Dismiss the hole service starts openvpn in user context. It makes no
>> sense.

> From a pure security perspective, you're right - maximum security would
> be reached by running openvpn.exe in a completely unprivileged context
> (unix way: chroot(/var/empty), setuid(nobody)) to make sure that any
> possible bug that is network-exploitable cannot be used to gain access
> to the system.

You misunderstood me, the feature openvpn service creates openvpn
process in user context didn't "work". It creates no additional
security but instead lower it (the service has the privilege to spawn
process in all user contexts).
It has nothing to do with privilege seperation.

My idea is the following:
run openvpnhelperservice with "network operator privileges", run
openvpn.exe als "local service", advance management interface to a
point that is more usefull. Let a client run in users context that
communicates via management interface.
The execution of scripts can be done from client if it's something
like pull git or connect to share.

> Given that people have implemented all the script and plugin hooks because
> someone actually *uses* them, taking this away would not be something
> people like - so you want something that has flexibility, but does not
> have "full system access" (unix: runs as root).

Are there any plugins for windows? What do they do? Do the need to run
in openvpn-context?

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Heiko Hund]

On Wednesday 29 February 2012 19:18:00 Carsten Krüger wrote:
> > If openvpn.exe startet in users context the user can manipulate it in
> > ram arbitrarily.
> 
> Example:
> http://blog.didierstevens.com/2009/06/25/bpmtk-injecting-vbscript/
> (great blog about process manipulation :-) )

Took a look, neat tool. In the same blog the author mentions that integrity 
levels, introduced in Vista, can be used to circumvent DLL injection. If that 
works out, all that is needed is the service increasing the tokens integrity 
level before starting openvpn and the user will have limited access to the 
running openvpn process.

http://blog.didierstevens.com/2010/09/07/integrity-levels-and-dll-injection/

Of course this makes only sense if the ongoing discussion about whether 
setting routes via --route config option comes to the conclusion "no". I'll 
follow up to Fabian about that.

Heiko
-- 
Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
 
Represented by the General Partner Astaro Verwaltungs GmbH
Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany 
Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

On Thu, Mar 1, 2012 at 11:24 AM, Heiko Hund  wrote:
>
> On Thursday 01 March 2012 09:22:38 Alon Bar-Lev wrote:
> > Also, (technically) impersonation token cannot be used for network
> > access.
> > So the solution of impersonating to user will not allow a script to
> > mount remote filesystem.
>
> You can't create a process with an impersonation token that's why a
> primary
> token is used.

How do you create primary token of user without him typing his
credentials again? or add the user "replace token" privilege?

Anyway, I am curios to read your view about the alternate solution I suggested.

Alon.

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

2012/3/1 Heiko Hund 
>
> On Wednesday 29 February 2012 18:43:18 Carsten Krüger wrote:
> > What operation could be in script that is usefull when it's executed
> > in user context.
>
> On Windows you could mount a CIFS share from the corporate LAN to the
> drive
> letter a user expects her data at, for example.

Right.
But this is similar to "logon script" just "connect script" which can
be run by the UI when it receives connect event.
Also, (technically) impersonation token cannot be used for network access.
So the solution of impersonating to user will not allow a script to
mount remote filesystem.

Alon.

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Heiko Hund]

On Wednesday 29 February 2012 18:43:18 Carsten Krüger wrote:
> What operation could be in script that is usefull when it's executed
> in user context.

On Windows you could mount a CIFS share from the corporate LAN to the drive 
letter a user expects her data at, for example.

Heiko
-- 
Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
 
Represented by the General Partner Astaro Verwaltungs GmbH
Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany 
Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

On Thu, Mar 1, 2012 at 12:45 AM, Jason Haar  wrote:
> A comment on your [1] reference. The issue of remote-user vs enterprise
> is an old one - that affects many software applications - not just
> openvpn. I personally think the proper solution is to implement NAC:
> make "the network/enterprise" audit the remote host and only allow it if
> it meets expectations. As such I don't think openvpn has to solve this
> problem itself, as "the enterprise" cares a lot more about the remote
> machine than whether or not the remote user has injected a couple of
> routes into the local routing table. eg Windows AV status.
>
> I think openvpn is quite entitled to act as a "mere" vpn solution, "the
> enterprise" should invoke a more over-arching solution (such as NAC with
> NAC agents) to ensure policy compliance.
>

Yes, and I guess you read to the end to the technical solution, right?
Do you have a comment about that?

Alon.