Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir
- 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
On Aug 27, 2012, at 08:11:53, Amm Vpnwrote: > 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
- 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
-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
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 Vpnwrote: 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
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