openvpn-devel Mailing List for OpenVPN

This add adds CID which is needed by a few other management commands to the status output. This will change the output of status in the same way commit ca18a638aa7cf316611f893127ba44131e57083c did. Signed-off-by: Arne Schwabe <ar...@rf...> --- src/openvpn/multi.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c index 9876b80..e5df432 100644 --- a/src/openvpn/multi.c +++ b/src/openvpn/multi.c @@ -807,8 +807,8 @@ multi_print_status (struct multi_context *m, struct status_output *so, const int */ status_printf (so, "TITLE%c%s", sep, title_string); status_printf (so, "TIME%c%s%c%u", sep, time_string (now, 0, false, &gc_top), sep, (unsigned int)now); - status_printf (so, "HEADER%cCLIENT_LIST%cCommon Name%cReal Address%cVirtual Address%cBytes Received%cBytes Sent%cConnected Since%cConnected Since (time_t)%cUsername", - sep, sep, sep, sep, sep, sep, sep, sep, sep); + status_printf (so, "HEADER%cCLIENT_LIST%cCommon Name%cReal Address%cVirtual Address%cBytes Received%cBytes Sent%cConnected Since%cConnected Since (time_t)%cUsername%cClient ID", + sep, sep, sep, sep, sep, sep, sep, sep, sep, sep); hash_iterator_init (m->hash, &hi); while ((he = hash_iterator_next (&hi))) { @@ -817,7 +817,7 @@ multi_print_status (struct multi_context *m, struct status_output *so, const int if (!mi->halt)	{ - status_printf (so, "CLIENT_LIST%c%s%c%s%c%s%c" counter_format "%c" counter_format "%c%s%c%u%c%s", + status_printf (so, "CLIENT_LIST%c%s%c%s%c%s%c" counter_format "%c" counter_format "%c%s%c%u%c%s%c%u", sep, tls_common_name (mi->context.c2.tls_multi, false), sep, mroute_addr_print (&mi->real, &gc), sep, print_in_addr_t (mi->reporting_addr, IA_EMPTY_IF_UNDEF, &gc), @@ -825,7 +825,8 @@ multi_print_status (struct multi_context *m, struct status_output *so, const int sep, mi->context.c2.link_write_bytes, sep, time_string (mi->created, 0, false, &gc), sep, (unsigned int)mi->created, - sep, tls_username (mi->context.c2.tls_multi, false)); + sep, tls_username (mi->context.c2.tls_multi, false), + sep, mi->context.c2.mda_context.cid);	} gc_free (&gc); } -- 1.7.9.6 (Apple Git-31.1) 

Am 28.02.10 17:46, schrieb Gert Doering: > Hi, > > On Sun, Feb 28, 2010 at 04:31:53PM +0100, David Sommerseth wrote: >>> In the grand scheme of things, small whitespace changes might later on >>> lead to a merge conflict with another patch in this line (like "introduce >>> version 4" or so), and so I'd avoid changes that are purely cosmetic in >>> a "feature" patch. >> Dang! This one slipped through. I spotted it, fixed it, but for some >> reason I recreated the patch file and forgot I had fixed it. Gert, I >> completely agree with you! > :) > >> I'll promise to fix this one when merging it into the git tree, is that >> good enough for you, Gert? > Yes, I'm fine with that. This patch is very old but since someone asked for this feature on IRC I am bringing this patch up again. I think it is good to have a stateless way (without being connected to the managament console all the time) to query the CID (client id). Is it better to a) break bad parsers when upgrading to 2.3 b) introduce a v4 format which only Arne 

On Fri, 31 Aug 2012 06:39:31 -0600, joshua gross <gro...@ho...> wrote: > Hi, > I working on an authentication plugin for openvpn (remote authentication). > I would like to be able to send a reason to the client for denying > authentication. Is this possible through a plugin? or the management > console? I've noticed that there is a command in the console > 'client-deny' that allows a client reason to be sent. But I have not > found a way to map a users common-name to their CID to use this command. > I only ask this as I use the common-name for authentication. Any help > would be appreciated. This was discussed a while ago here: http://thread.gmane.org/gmane.network.openvpn.user/33106/ -- D. 

Hi, I working on an authentication plugin for openvpn (remote authentication). I would like to be able to send a reason to the client for denying authentication. Is this possible through a plugin? or the management console? I've noticed that there is a command in the console 'client-deny' that allows a client reason to be sent. But I have not found a way to map a users common-name to their CID to use this command. I only ask this as I use the common-name for authentication. Any help would be appreciated. Thanks, Joshua G 

Hi David On Tuesday 14 August 2012 11:57:29 David Sommerseth wrote: > This will cause a warning in the log file if --client-config-dir > is configured but OpenVPN could not find or open the config file > for the connecting client. There should only be a warning message if --ccd-exclusive is active. Otherwise mixed setups, where some users have a CCD entry and others use just the basic settings, will end up with a overly polluted log file. Adding a DEFAULT file somehow defeats the purpose of CCDs. However, with --ccd-exclusive there already is a error message, generated in ssl_verify.c: "TLS Auth Error: --client-config-dir authentication failed for common name '%s' file='%s'". Regards Heiko -- Heiko Hund | Sr. Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany 

Hi, On Tue, Aug 14, 2012 at 11:57:29AM +0200, David Sommerseth wrote: > From: David Sommerseth <da...@re...> > > This will cause a warning in the log file if --client-config-dir > is configured but OpenVPN could not find or open the config file > for the connecting client. > > OpenVPN will also look for a file named 'DEFAULT' if a file named > as the client's TLS Common Name cannot be found. To hide this > warning above, create an empty 'DEFAULT' file inside the > --client-config-dir. I'm not sure I'm happy with that... > + else > + { > + msg (M_WARN, "[CCD] Failed to import client config for '%s'", > + tls_common_name (mi->context.c2.tls_multi, false)); > + } I find the actual message confusing - what does "fail to *import*" mean? Naive interpretation is "the file could be found, but there's something broken with it, like 'syntax errors' or such, but we won't tell you!". So the message should be more along the lines of: msg (M_WARN, "[CCD] client config file for '%s' not found (or unreadable), and no DEFAULT file either", (while it would be even more nice to show *why* it fails, I can see that this is a bit tricky to get done without quite some extra code to remember test results, etc.) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

 ----- Original Message ----- > From: Eric Crist <ec...@se...> > 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 

On Aug 27, 2012, at 08:11:53, Amm Vpn <amm...@ya...> 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 

 ----- Original Message ----- > From: David Sommerseth <ope...@to...> > To: Amm Vpn <amm...@ya...> > Cc: "ope...@li..." <ope...@li...> > 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 script comes, I will have to modify frontend to check that too and then update all the machines with new frontend. 3) Other way is to write a full-fledged key-value based form (instead of textarea) where only allowed config parameters are modify-able. But then this itself will be big code and every time a modify-able item is to be added or removed, frontend needs to be changed at all sites. Like if new feature is added, I will have to enable that in frontend at all sites. If I need to remove deprecated feature I will have to delete that in front end in all locations. There can be few other ways which I am not sure. Like I am not sure if I should check for "--cd" and "--chroot". I need to think if this can be used to bypass things in frontend. But that later. As you can see its not easy to write a front end which considers all the cases of security. One slip in check and hostile admin can trigger "rm -rf /" on system. I would never ASSUME that my code is fool-proof. And writing such a frontend itself will run into writing 100-125 lines of code whereas patch I submitted is just 25 lines or so and it will always be future compatible whatever new types of script is added in future. 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". My idea is to keep things simple and future compatible. Instead of thinking, re-evaluating everytime a new version of OpenVPN comes. If you just implement "script-dir", "rm -rf /" will simply never run. > 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. Exactly my point security needs to be tackled on place you fully control. You think frontend is what we control. I think OpenVPN is what we control. With my patch *no matter* what happens on frontend, even if you forget to check something else, no matter what new script-type is added. User will never be able to trigger "rm -rf /" because its been controlled right at OpenVPN level. So please give a thought again. Thanks, AMM. 

-----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----- 

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 <amm...@ya...> 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 <ope...@to...> > 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 Ope...@li... https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

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 <ope...@to...>   > 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 

 NAK again. This still does not belong in the core OpenVPN, IMO. If you want to have this feature, you need to enforce this in your front-end where you sanitise the config *before* OpenVPN is started. Which was my conclusion from the last time as well. 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. 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. So bottom line is: This approach does not make sense to apply to the OpenVPN executable. You need to ensure the configs are trustful with a completely different approach. kind regards, David Sommerseth On 08/24/2012 07:17 PM, Amm Vpn wrote: > Hello all, > > I am attaching a new patch which takes care of few things discussed yesterday. > > Summary of patch: > 1) Add new option --script-dir which restricts any user defined script to run only from specific directory > > 2) Backward compatible. If script-dir is not specified then it allows script from any directory. > > > 3) Adds compile time configure option --with-script-dir=/some/path/ > If this option is used then script-dir becomes hard-coded and CAN NOT be changed from config file or command line. > > > This allows flexibility to anyone (people like me) who wants to compile the code on their own making sure that script-dir can not be changed at all. > > > 4) If it is not enabled at compile time then first script-dir has preference. > a) if script-dir is specified on command line, it is given the priority > > b) if script-dir is specified twice (either in same config file or included config file) then only 1st occurrence is accepted and warning is logged for the rest of the occurrences. > > > This allows, easy binary distribution (by not hard-coding the script-dir) and then user can decide on their own script-dir. > > Root user can then call OpenVPN with script-dir either on command line or inside parent config file. Parent config file can then call child config (config child.conf). And then "freely" give access to child.conf to other lower admins without worrying about them running any random script. > > Even if lower admins specify script-dir, it will be ignored. > > > > Hope that this patch now satisfy everyone in devel group and makes much more sense to be implemented. > > Security in my opinion should be prime concern especially when we know that there is a way to run any random script. And hence atleast for such insecure options, sanity checks has to be there in program itself instead of trusting the frontend. > > > > > Patch is clean and simple and just about 25 lines of real code addition. > > Patch eliminates danger of openvpn running any script blindly. > > So please review it and consider to merge in source tree. > > Thank you > > 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Hello all, I am attaching a new patch which takes care of few things discussed yesterday. Summary of patch: 1) Add new option --script-dir which restricts any user defined script to run only from specific directory 2) Backward compatible. If script-dir is not specified then it allows script from any directory. 3) Adds compile time configure option --with-script-dir=/some/path/ If this option is used then script-dir becomes hard-coded and CAN NOT be changed from config file or command line. This allows flexibility to anyone (people like me) who wants to compile the code on their own making sure that script-dir can not be changed at all. 4) If it is not enabled at compile time then first script-dir has preference. a) if script-dir is specified on command line, it is given the priority b) if script-dir is specified twice (either in same config file or included config file) then only 1st occurrence is accepted and warning is logged for the rest of the occurrences. This allows, easy binary distribution (by not hard-coding the script-dir) and then user can decide on their own script-dir. Root user can then call OpenVPN with script-dir either on command line or inside parent config file. Parent config file can then call child config (config child.conf). And then "freely" give access to child.conf to other lower admins without worrying about them running any random script. Even if lower admins specify script-dir, it will be ignored. Hope that this patch now satisfy everyone in devel group and makes much more sense to be implemented. Security in my opinion should be prime concern especially when we know that there is a way to run any random script. And hence atleast for such insecure options, sanity checks has to be there in program itself instead of trusting the frontend. Patch is clean and simple and just about 25 lines of real code addition. Patch eliminates danger of openvpn running any script blindly. So please review it and consider to merge in source tree. Thank you AMM. 

Hi, On Thu, Aug 23, 2012 at 11:21:00PM +0200, Arne Schwabe wrote: > This patch documents the usage of inline files in OpenVPN. Hackish ways of inline files are deliberately left out. For tls-auth and ACK. (This is far too useful to be left undocumented :-) ) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

This patch documents the usage of inline files in OpenVPN. Hackish ways of inline files are deliberately left out. For tls-auth and secret the key-direction option is right way of specifying the direction and not by using two tls-auth/secret lines where the first sets the direction and has a dummy file name and the second sets the inline file data but does not reset the direction parameter. Also pkcs12 [[INLINE]] base64encoded_data works but is a quirk of how the config parser works Signed-off-by: Arne Schwabe <ar...@rf...> --- doc/openvpn.8 | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index a821b5e..49348e4 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -3615,6 +3615,14 @@ would see nothing but random-looking data. .\"********************************************************* .TP +.B \-\-key-direction +Alternative way of specifying the optional direction parameter for the +.B \-\-tls-auth +and +.B \-\-secret +options. Useful when using inline files (See section on inline files). +.\"********************************************************* +.TP .B \-\-auth alg Authenticate packets with HMAC using message digest algorithm @@ -5895,6 +5903,37 @@ X509_1_C=KG .ft .fi .\"********************************************************* +.SH INLINE FILE SUPPORT +OpenVPN allows including files in the main configuration for the +.B \-\-ca, \-\-cert, \-\-dh, \-\-extra-certs, \-\-key, \-\-pkcs12, \-\-secret +and +.B \-\-tls-auth +options. + +Each inline file started by the line +.B <option> +and ended by the line +.B </option> + +Here is an example of an inline file usage + +.nf +.ft 3 +.in +4 +<cert> +-----BEGIN CERTIFICATE----- +[...] +-----END CERTIFICATE----- +</cert> +.in -4 +.ft +.fi + +When using the inline file feature with +.B \-\-pkcs12 +the inline file has to be base64 encoded. Encoding of a .p12 file into base64 can be done for example with OpenSSL by running +.B openssl base64 -in input.p12 + .SH SIGNALS .TP .B SIGHUP -- 1.7.9.5 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/08/12 17:30, Amm Vpn wrote: > > Currently openvpn BLINDLY runs any script which in my opinion is > too dangerous. One breach and intruder can simply erase your whole > harddisk. Agreed. > My idea of script-dir is taken from sendmail concept of smrsh. > http://www.faqs.org/docs/securing/chap22sec182.html > > In my case person does not have direct access to machine. But only > to config file. Now if I make sure that he cant change script-dir, > it secures my whole machine. > > Otherwise there is noway I can give access to config file to him > without worrying about him running "rm -rf /" > > Hope I am able to convey my idea. Just trying to patch a flaw in > openvpn, in my opinion But you forget one detail. OpenVPN options can be overridden by just appending an extra --script-dir at the command line, due to the nature of the option parser. Which is the same situation for - --script-security as well. Your patch has the same flaw as - --script-security. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA2TzgACgkQDC186MBRfrrWwgCeOHVUDUWVfSPVoFSSet1BlBU8 fQMAn0Pw9ia3cKkW1wXe3R65brcjHmIV =ZBlP -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/08/12 15:09, amm...@ya... wrote: > Hello all, > > I am submitting a minor patch which includes an option to specify > --script-dir. > i.e. any user defined script will be run ONLY IF it is present in > "script-dir". > > The reason I needed this is because I had a frontend to configuration > file which allowed administrator to change configuration. > > I also have script-security set to 2 because I wanted to run a script > when client connects. > > These two option make it insecure. As admin (with bad intention or if > admin password is leaked) can simply call "rm -rf /" for certain commands. > > So my idea was > 1) Add a new option called script-dir > 2) Frontend will not allow word "script-dir" in config file (so admin > cant change it) > 3) script-dir will be passed on command line > > This way admin can not run anything other than what I have put in > script-dir. This also helps prevent accidentally run script in some > other path. This patch will indeed do what you propose, and to some degree I can see the purpose. But this kind of sanity checks does not belong inside OpenVPN, IMO. Putting it here, is the most difficult place to put it. There are two approaches for this kind of security. If you have a gun, you can either lock it safely inside some lockers, to avoid your kids playing with it. Or you can add an advanced trigger mechanism which checks if it's an adult holding the gun when trigger is pushed. Then let your gun float around on the floors where you find it practical, not minding your kids playing with it. The approach on your patch reminds me of the latter one. I suggest going for the former one. Rather design your solution so that the OpenVPN executable can 100% trust the input it is given, effectively putting the responsibility for security/sanity to the front-end which starts OpenVPN. Your patch also adds the condition that *any* front-end cannot allow "script-dir" in the configs. Which means more GUIs needs to be modified to filter out this statement from users configs, if found. This won't work out in reality. I'm also worried about potential ways this can be abused as well. Something along where the sysadmin prepares /usr/share/openvpn/scripts as the place for all safe scripts. And somehow the user manages to replace this path with /home/mrevil/myscripts ... and then these "evil scripts" in that directory are run with elevated privileges. In this case, --script-dir would cause a false sense of security. Also adding this as a runtime parameter is tricky, as the options parser is recursive. Lets take an example with three config files and a command line override: ....config-1.cnf...... dev tun config config-inc.cnf ...................... ....config-inc.cnf... key client.key cert client.crt ca ca.crt ..................... ....config-client.cnf..... client remote x.x.x.x 1194 .......................... And from the command line: $ openvpn --config config-client.cnf \ --remote y.y.y.y --config config-1.cnf (of course, it's not a complete config ... but you hopefully get the idea) And adding --script-dir in a safe way to avoid this to be abused requires a much more well thought patch than this simple approach you suggested here. From where should --script-dir be allowed, and in which order? All to avoid being overridden somehow. To make your idea bullet-proof inside OpenVPN, --script-dir would have to be a compile time restriction, where OpenVPN is hard-coded with which directory to trust. But this won't scale well, as then each who wants this needs to compile their own OpenVPN according to their requirements. So for me, it makes more sense to put this --script-dir feature into the GUI/front-end, where it can better do the proper sanity checks of the configs, and prepare a sanctioned openvpn command line *before* OpenVPN is started. This way it will be harder to abuse OpenVPN, if the openvpn binary is well protected. This way we can also keep OpenVPN simpler, and still stay flexible for those who need more flexibility too. And I hope to see that we can reduce the complexity of OpenVPN even further, preferably so much that it can be configured to be started completely by an unprivileged user on all platforms and still being able to configure the network correctly. The default approach of OpenVPN currently is to depend on root/admin privileges for network configurations. Bottom line is, I'm giving a NAK to this patch. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA2ThsACgkQDC186MBRfrpfAACgjBKKp5I6VByWqYutsuw6l227 698AnRb0MfO0MyAk0CPtWoMAbCPCulA9 =60wm -----END PGP SIGNATURE----- 

On Aug 23, 2012, at 10:30:51, Amm Vpn <amm...@ya...> wrote: > ----- Original Message ----- >> From: Eric Crist <ec...@se...> >> To: Amm Vpn <amm...@ya...> >> Cc: Heiko Hund <hei...@so...>; "ope...@li..." <ope...@li...> >> Sent: Thursday, 23 August 2012 8:19 PM >> Subject: Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir > >>> So best is to make OpenVPN itself secure. And run only scripts from >>> particular directory. (script-dir) > > >> I don't really see how this adds any security. Perhaps it makes it easier >> to code your front-end, but it doesn't offer anything in the way of >> security, since it's an option passed in the config or on the command line, >> it can be changed at-will by whomever runs the program. > > Umm, same applies for script-security parameter as well. How does that add security? > If person has access to config file he can change script-security level as well and then > run any RANDOM command at his will. > > So why was such an option added too? Please do not assume that it will be only you who would > be modifying config file. In my case I have to allow access to subordinate. > > My point here is script-security does not really give you TRUE security. > > Script-dir makes sure that ONLY script from particular directory (say /etc/openvpn/scripts) > are run. This should infact be hardcoded in openvpn at compile time. (which my patch > does not do yet but instead made is config option) > > Any script NOT in that directory should not be run at all. > > Currently openvpn BLINDLY runs any script which in my opinion is too dangerous. One > breach and intruder can simply erase your whole harddisk. > > My idea of script-dir is taken from sendmail concept of smrsh. > http://www.faqs.org/docs/securing/chap22sec182.html > > In my case person does not have direct access to machine. But only to config file. > Now if I make sure that he cant change script-dir, it secures my whole machine. > > Otherwise there is noway I can give access to config file to him without worrying > about him running "rm -rf /" > > Hope I am able to convey my idea. Just trying to patch a flaw in openvpn, in my opinion I still think this doesn't help anything that can't be solved in your own GUI. Simply make sure that you prepend the full path on any scripts setup from your front-end and you help your own cause. Additionally, strip any pathing from the supplied arguments. script-security was added by James before the community got heavily involved in development, so I can't say as to the real reasons for that change. I am still thinking this is an unneeded patch with too-narrow a scope. ----- Eric F Crist 

 ----- Original Message ----- > From: Eric Crist <ec...@se...> > To: Amm Vpn <amm...@ya...> > Cc: Heiko Hund <hei...@so...>; "ope...@li..." <ope...@li...> > Sent: Thursday, 23 August 2012 8:19 PM > Subject: Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir   >> So best is to make OpenVPN itself secure. And run only scripts from >> particular directory. (script-dir) > I don't really see how this adds any security.  Perhaps it makes it easier > to code your front-end, but it doesn't offer anything in the way of > security, since it's an option passed in the config or on the command line, > it can be changed at-will by whomever runs the program. Umm, same applies for script-security parameter as well. How does that add security? If person has access to config file he can change script-security level as well and then run any RANDOM command at his will. So why was such an option added too? Please do not assume that it will be only you who would be modifying config file. In my case I have to allow access to subordinate. My point here is script-security does not really give you TRUE security. Script-dir makes sure that ONLY script from particular directory (say /etc/openvpn/scripts) are run. This should infact be hardcoded in openvpn at compile time. (which my patch does not do yet but instead made is config option) Any script NOT in that directory should not be run at all. Currently openvpn BLINDLY runs any script which in my opinion is too dangerous. One breach and intruder can simply erase your whole harddisk. My idea of script-dir is taken from sendmail concept of smrsh. http://www.faqs.org/docs/securing/chap22sec182.html In my case person does not have direct access to machine. But only to config file. Now if I make sure that he cant change script-dir, it secures my whole machine. Otherwise there is noway I can give access to config file to him without worrying about him running "rm -rf /" Hope I am able to convey my idea. Just trying to patch a flaw in openvpn, in my opinion    Amm 

On Aug 23, 2012, at 09:45:14, Amm Vpn <amm...@ya...> wrote: >> Hi >> >> On Thu 23 08 2012 21:09:49 amm...@ya... wrote: >>> So my idea was >>> 1) Add a new option called script-dir >>> 2) Frontend will not allow word "script-dir" in config file (so admin cant >>> change it) >>> 3) script-dir will be passed on command line >>> >>> This way admin can not run anything other than what I have put in >>> script-dir. This also helps prevent accidentally run script in some other >>> path. >> >> As this is very specific to you frontend, why doesn't your frontend simple >> check the path names in the config for correctness before deploying it? > > Umm, I suppose this feature may be useful for other purposes. Atleast adds a level of security. > > Regarding my frontend, frontend is very basic, Simple textarea in a form. > I do not want to complicate it by parsing each line, each type of config value and verifying them for > correctness and secureness. > > Also want it to be forward compatible, in a sense, lets say tomorrow some other config is > introduced which runs some other script. Then I do not want to re-code my frontend to > check for new config entry. > > So best is to make OpenVPN itself secure. And run only scripts from particular directory. (script-dir) I don't really see how this adds any security. Perhaps it makes it easier to code your front-end, but it doesn't offer anything in the way of security, since it's an option passed in the config or on the command line, it can be changed at-will by whomever runs the program. ----- Eric F Crist 

 Hi >________________________________ > From: Heiko Hund <hei...@so...> >To: ope...@li...; "amm...@ya..." <amm...@ya...> >Sent: Thursday, 23 August 2012 7:15 PM >Subject: Re: [Openvpn-devel] patch for 2.2.2 to include --script-dir > >Hi > >On Thu 23 08 2012 21:09:49 amm...@ya... wrote: >> So my idea was >> 1) Add a new option called script-dir >> 2) Frontend will not allow word "script-dir" in config file (so admin cant >> change it) >> 3) script-dir will be passed on command line >> >> This way admin can not run anything other than what I have put in >> script-dir. This also helps prevent accidentally run script in some other >> path. > >As this is very specific to you frontend, why doesn't your frontend simple >check the path names in the config for correctness before deploying it? Umm, I suppose this feature may be useful for other purposes. Atleast adds a level of security. Regarding my frontend, frontend is very basic, Simple textarea in a form. I do not want to complicate it by parsing each line, each type of config value and verifying them for correctness and secureness. Also want it to be forward compatible, in a sense, lets say tomorrow some other config is introduced which runs some other script. Then I do not want to re-code my frontend to check for new config entry. So best is to make OpenVPN itself secure. And run only scripts from particular directory. (script-dir) Regards Amm. 

Hi On Thu 23 08 2012 21:09:49 amm...@ya... wrote: > So my idea was > 1) Add a new option called script-dir > 2) Frontend will not allow word "script-dir" in config file (so admin cant > change it) > 3) script-dir will be passed on command line > > This way admin can not run anything other than what I have put in > script-dir. This also helps prevent accidentally run script in some other > path. As this is very specific to you frontend, why doesn't your frontend simple check the path names in the config for correctness before deploying it? Regards Heiko -- Heiko Hund | Sr. Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany 

Hello all, I am submitting a minor patch which includes an option to specify --script-dir. i.e. any user defined script will be run ONLY IF it is present in "script-dir". The reason I needed this is because I had a frontend to configuration file which allowed administrator to change configuration. I also have script-security set to 2 because I wanted to run a script when client connects. These two option make it insecure. As admin (with bad intention or if admin password is leaked) can simply call "rm -rf /" for certain commands. So my idea was 1) Add a new option called script-dir 2) Frontend will not allow word "script-dir" in config file (so admin cant change it) 3) script-dir will be passed on command line This way admin can not run anything other than what I have put in script-dir. This also helps prevent accidentally run script in some other path. Patch also fixes minor bug in init.c where warning for SSEC_PW_ENV actually would never be shown. So please have a look at it and if acceptable then merge in source tree. Thanks AMM. 

Sure, no problem! When I uses OpenVPN 2.2.2 on Windows 7 64-bit I also could execute openvpn in console with any config-file and the connection was established. Now with OpenVPN 2.3 alpha the TLS config files works fine with GUI but not via console. Via console the connection will be established but the OpenVPN network adapter will be not connected (cable is removed). This I think is a bug in 2.3 alpha, because this worked with 2.2.2. Regards, MF 2012/8/20 Heiko Hund <hei...@so...>: > Hi Markus > > On Monday 20 August 2012 12:27:29 David Sommerseth wrote: >> I just checked the source code quickly, and it certainly looks like >> - --tls-exit depends on tls-server or tls-client. Or to say it easier, >> it requires --key, --cert and --ca in the config file. (--server and >> - --client are kind of macros, which then implies enabling --tls-server >> or --tls-client, but bot requires --key, --cert and --ca) >> >> So if your configuration file does not have --tls-exit explicitly >> mentioned, it sounds like it's the GUI doing this. I would then >> probably report it as a GUI bug [1]. > > No need to, really. I'm aware of the bug and will fix it this week. > Could you test a fixed GUI I provide? > > Heiko > -- > Heiko Hund | Sr. Software Engineer | Tel +49-721-25516-237 | Fax -200 > SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany >