Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir

[Amm Vpn]

- Original Message -

> From: Eric Crist 

> All of this can be solved with sed.  No need for an OpenVPN patch that simply 
> makes your life a little easier.  This hasn't been requested by 
> 'many' users, like you claim.  It's only been requested by you.

Ok. No issues. However, I dont think sed solves this.

AMM

Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir

[Eric Crist]

On Aug 27, 2012, at 08:11:53, Amm Vpn  wrote:

> With my idea of simple textarea HTML field, local admin himself (without 
> needing me)
> can enable a feature or remove deprecated feature by simply adding/removing
> related line. All I have to make sure that disallow word "script-dir" in 
> frontend.
> And may be few other keywords like "chroot".

All of this can be solved with sed.  No need for an OpenVPN patch that simply 
makes your life a little easier.  This hasn't been requested by 'many' users, 
like you claim.  It's only been requested by you.

-
Eric F Crist

Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir

[Amm Vpn]

- Original Message -
> From: David Sommerseth 
> To: Amm Vpn 
> Cc: "openvpn-devel@lists.sourceforge.net" 
> 
> Sent: Monday, 27 August 2012 3:46 PM
> Subject: Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir
> 


Hi,

First of all thanks for taking time out to reply.

But based on your replies, I believe you have not understood why I am
proposing this patch. The cases you are talking appear completely
irrelevant to my (and many other) situations.

Let me explain the situation.
1) We are evaluating OpenVPN for connecting 15-20 locations.

2) We liked it, seems quite convenient.
[SIde note: Even if you do not accept the patch we will still go ahead
and patch our own copy of OpenVPN. But we believe in contributing
back. We thought this is any important patch so we are proposing
(but not trying to force) this patch]

3) I am the one who verifies about how secure the code is and if it
insecure, then I try to patch it. If it can not be easily patched, we drop it.

4) Noone has root access to system. Noone can change anything by
directly modifying the file on the system via shell.

5) There is password protected web frontend (a textarea HTML field)
where select files can be directly edited by those having password.

This situation (point 4-5) will be true for many other companies as well.
Where people have separate account for accessing frontend. Not just
for OpenVPN but for many other daemons running. Webmin is perfect
example for such a system. (Though we are not using webmin for OpenVPN)

Webmin also specifies which admin has access to what module. For now
please assume that we are using system somewhat similar to webmin.
But an inhouse developed system.

I hope I have explained the situations. So now lets go ahead to your
reasons for not including the patch. And why I think the reasons are
irrelevant.


> a) The user can after having established a connection do a 'ps' and
> list all openvpn processes and it's arguments.  Save this and disconnect.

Not possible in situation I have explained.

> b) Download it's own source code of OpenVPN, and compile it.  Either
> on the same box (if all needed tools are needed) or another one with
> same libraries and copy over the new executable.

Again not possible in situation I have explained.

> c) Modify the $PATH variable ... or try different approaches to run
> its own compiled OpenVPN binary with a modified configuration file
> (without --script-dir).

Again not possible in situation I have explained. But you mentioned
without --script-dir which indirectly means that script-dir would have
made it secure.(which is why I am proposing this)

> And if that doesn't work ... the user can boot the box into
> single-user mode, or with a rescue disk ... and forcefully replace
> your openvpn binary on the filesystem.

Again no physical access. I wonder why are you talking about
this and why you have made this as base for rejecting script-dir??

With this argument, I can simply reject all the security code that has
ever been written in whole world. I can even say we dont need
file permissions that UNIX system gives. We dont need SELINUX
and blah blah.. because user can boot the box in single user mode
and do whatever?

I hope I make some sense here.

> And how does --script-dir change anything in regards to security in here?
> 
> A more sane approach to avoid users from execute random scripts as
> root is to:
> 
>   1. have openvpn somewhere on the disk where only root can access and
>      execute the binary.

Yes this is what we have.

>   2. Save configs in a directory where only root can read/write and do
>      not allow the user to even read these config files at all.

Yes this is what we have.

>   3. Have a "kick-off" service running, which just takes a reference
>      to a configuration file, which can start the openvpn process
>      with the appropriate config - and nothing more.  This needs to be
>      run with root privileges.

Ok ...

>   4. Have a front-end which the user runs completely unprivileged, which
>      contacts the "kick-off" service with info about which config to
>      start.

Ok ...

> Point 3 and 4 is outside the core part of OpenVPN.

Agreed ...

> Bottom line is, you need to ensure that your configuration files are
> to be trusted.  Telling OpenVPN to bailout if one of the paths in the
> config file is wrong, won't add much to improve this situation.  That's
> more an annoyance than anything else.

Ok now let me tell you how many things I will have to check IF I DONT
patch with script-dir. (this will be true for any frontend developer not
just me)

1) I will have to verify for each types of script that openvpn can run.
Currently, it can be one of the following: (taken from man page)
up, down, ipchange, route-up, tls-verify, auth-user-pass-verify, client-connect,
client-disconnect, or learn-address.

2) Tomorrow if new type of 

Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/08/12 03:24, Amm Vpn wrote:
> Hi,
> 
> First I just wanted to know if you are the decision maker for
> OpenVPN?

I am one of more.  But I'm kind of the main community gatekeeper for
the public git trees.  Patches go through me.  But I listen to the
majority of the trusted community members.  Eric is one of them, Heiko
is another one.  But feel free to approach OpenVPN technology people
directly, if you prefer that.

> Because, the reasons/scenarios you are giving do not make sense to
> me. You are not at all considering the real danger (a what-if
> case)
> 
> (Do not take it in offensive way please)

No problem.  But I thought I already did that, even though not
explicitly.  But from what I understand your clients are Linux or BSD
based.  And I still do not see your approach as useful.

a) The user can after having established a connection do a 'ps' and
list all openvpn processes and it's arguments.  Save this and disconnect.

b) Download it's own source code of OpenVPN, and compile it.  Either
on the same box (if all needed tools are needed) or another one with
same libraries and copy over the new executable.

c) Modify the $PATH variable ... or try different approaches to run
its own compiled OpenVPN binary with a modified configuration file
(without --script-dir).

And if that doesn't work ... the user can boot the box into
single-user mode, or with a rescue disk ... and forcefully replace
your openvpn binary on the filesystem.

And how does --script-dir change anything in regards to security in here?

A more sane approach to avoid users from execute random scripts as
root is to:

  1. have openvpn somewhere on the disk where only root can access and
 execute the binary.

  2. Save configs in a directory where only root can read/write and do
 not allow the user to even read these config files at all.

  3. Have a "kick-off" service running, which just takes a reference
 to a configuration file, which can start the openvpn process
 with the appropriate config - and nothing more.  This needs to be
 run with root privileges.

  4. Have a front-end which the user runs completely unprivileged, which
 contacts the "kick-off" service with info about which config to
 start.

Point 3 and 4 is outside the core part of OpenVPN.

This is the only way you can be sure the configurations can't be
modified by the user *except* if the user boots the box using a rescue
tool or similar, where it gains root access to the file system.  Then
the game is lost.

Bottom line is, you need to ensure that your configuration files are
to be trusted.  Telling OpenVPN to bailout if one of the paths in the
config file is wrong, won't add much to improve this situation.  That's
more an annoyance than anything else.

In general, you can't trust any clients.  Security needs to be tackled
on the places you fully control and where the clients have no
possibility to gain root access.  In the moment the user can get root
access somehow, you're out of control.


kind regards,

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

iEYEARECAAYFAlA7SOgACgkQDC186MBRfrpX7wCfdEUvdSUtnj2svgJKE4WswAYO
bnQAoJU1QyBLtC+6/4dNJDB+oX3ZHB2i
=ApYy
-END PGP SIGNATURE-

Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir

[Eric F Crist]

There are a few decision makers who have sent NAKs regarding your patch. This 
isn't going to be considered further. 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Amm Vpn  wrote:

Hi,

First I just wanted to know if you are the decision maker for OpenVPN?


Because, the reasons/scenarios you are giving do not make sense to me.
You are not at all considering the real danger (a what-if case)

(Do not take it in offensive way please)

I just wanted to make sure I am posting the patch at right place and to
right person.


I am talking about two users here, one the root user who has access to
system and other a plain admin who has access to config file only.
This is a real world scenario in most of cases where assistant just has
access to frontend and IT head has root access.



- Original Message -
> From: David Sommerseth 
 
> Having this as a runtime configuration does not add any restriction in 
> reality.  You must presume the user have the possibility to tweak the config 
> somehow.  And the user is fully capable of discovering a way how to execute 
> your configs directly, skipping the --scripts-dir.  So you cannot trust the 
> client config.  So the front-end must protect the OpenVPN executable so it is 
> the only one who can start an OpenVPN connection.

Can you tell me how user can skip script-dir in my new patch? With example
config? In my opinion I have already taken care of it, if not then I am ready to
patch that as well.


> Another scenario, if your front-end does not protect the OpenVPN binary, a 
> user can also download an earlier OpenVPN and circumvent this behaviour with 
> your own front-end.  So the OpenVPN executable must be protected no matter 
> what, and your front-end is the only thing which the user should be able to 
> use.  And then this front-end is the only one which truly can protect you, by 
> sanitising the config *before* the OpenVPN executable is started - where your 
> front-end is the only binary which should have access to the OpenVPN binary.

Isnt that true for any software?? That user can install unpatched binary and do
whatever?? Its like saying, "Hey there is another way a thief can enter the 
house,
so why not let all the doors open?"

And again in my case (infact in most case where root and frontend is handled
by different people) this would again not be case. As frontend guy has no root
access, so cant install unpatched version.

Thanks and regards,

AMM


_

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_

Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir

[Amm Vpn]

Hi,

First I just wanted to know if you are the decision maker for OpenVPN?


Because, the reasons/scenarios you are giving do not make sense to me.
You are not at all considering the real danger (a what-if case)

(Do not take it in offensive way please)

I just wanted to make sure I am posting the patch at right place and to
right person.


I am talking about two users here, one the root user who has access to
system and other a plain admin who has access to config file only.
This is a real world scenario in most of cases where assistant just has
access to frontend and IT head has root access.



- Original Message -
> From: David Sommerseth 
 
> Having this as a runtime configuration does not add any restriction in 
> reality.  You must presume the user have the possibility to tweak the config 
> somehow.  And the user is fully capable of discovering a way how to execute 
> your configs directly, skipping the --scripts-dir.  So you cannot trust the 
> client config.  So the front-end must protect the OpenVPN executable so it is 
> the only one who can start an OpenVPN connection.

Can you tell me how user can skip script-dir in my new patch? With example
config? In my opinion I have already taken care of it, if not then I am ready to
patch that as well.


> Another scenario, if your front-end does not protect the OpenVPN binary, a 
> user can also download an earlier OpenVPN and circumvent this behaviour with 
> your own front-end.  So the OpenVPN executable must be protected no matter 
> what, and your front-end is the only thing which the user should be able to 
> use.  And then this front-end is the only one which truly can protect you, by 
> sanitising the config *before* the OpenVPN executable is started - where your 
> front-end is the only binary which should have access to the OpenVPN binary.

Isnt that true for any software?? That user can install unpatched binary and do
whatever?? Its like saying, "Hey there is another way a thief can enter the 
house,
so why not let all the doors open?"

And again in my case (infact in most case where root and frontend is handled
by different people) this would again not be case. As frontend guy has no root
access, so cant install unpatched version.

Thanks and regards,

AMM