Re: [Openvpn-devel] Architecture diagram & Theory of Operation documents

[Peter Stuge]

john s wolter wrote:
> When it comes to debugging problems inside OpenVPN and other FOSS
> software there is a lack of design information.

I disagree that this is relevant for debugging.


> Architecture diagram & Theory of Operation documents are a minimum
> starting point for those not directly involved in development.

Again, I disagree.

Such documentation is indeed good for some things, but as far as
interaction between PKCS#11 providers and PKCS#11 users I actually
think the need is for *less* documentation. :) There is the PKCS#11
standard, but it doesn't provide much overview, it mostly focuses on
matters relevant for implementation of PKCS#11.

There should be fairly much accessible documentation on PKCS#11
online already.

What Jan describes happening in OpenVPN doesn't make a lot of sense
and is "simply" a bug that should be investigated and fixed.


> Do you have a link to these documents?

Until you or someone else writes them, they don't exist. Indeed your
help with this would be most welcome!


//Peter

[Openvpn-devel] Architecture diagram & Theory of Operation documents

[john s wolter]

I'm writing in response to this posting subject..
"Re: [Openvpn-devel] VERY weird interaction between openvpn and
opensc-pkcs11"

When it comes to debugging problems inside OpenVPN and other FOSS software
there is a lack of design information.  Architecture diagram & Theory of
Operation documents are a minimum starting point for those not directly
involved in development.  Do you have a link to these documents?

These documents will greatly improve the way OpenVPN works and how it should
be install and debugged.

Cheers.
-
John S. Wolter

Mailto:johnswol...@wolterworks.com
Desk Phone: 734-408-1263
Cell phone: 734-904-8433
USA, Eastern Standard Time, -5 GMT, -4 GMT DST

- Cloud based web services
- Virtual Office services
- Software Development
- Engineered applications





On Thu, Nov 11, 2010 at 9:32 AM, Jan Just Keijser  wrote:

> hi all,
>
> I just spent almost a day debugging a very weird interaction between
> OpenVPN 2.1 and opensc-pkcs11 :
>
> Hardware:
> a Feitian ePass smartcard with an Omnikey CardMan 3121 card reader
>
> Software:
> openvpn 2.1.3
> opensc 0.12.0 (not officially released yet)
> pkcs11-helper 1.07
> linux 2.6.34 64bit kernel (fc13)
>
> Here's what happens:
>
> openvpn starts up, queries me for the PKCS11 prompt, connection is
> established alright.
> When I look at the log file (with 'verb 99') I see that the pkcs11
> function __pkcs11h_forkFixup is called several times, with a different
> pid=%d value every time. This is bad, as it causes opensc-pkcs11 to
> reload the card every time (it calls C_Finalize then C_Initialize). This
> operation is very expensive.
> During key renegotiation it gets even worse, as openvpn prompts me for
> the PIN again and connectivity is lost until I enter the PIN.
>
> Now here's the weirdest part:
>
> the __pkcs11h_forkFixup function is called after the invocation of an
> external program (e.g. /sbin/ip link , /sbin/ip/addr add etc). If I use
>  script-security 2 system
> the openvpn_execve function uses 'system()' calls to start these
> programs and the problem goes away !
>
> So it seems that openvpn's openvpn_execve fork+waitpid function causes
> the program pid to change every time, triggering the reset of the pkcs11
> interface !
>
> What shall we do about this?
>
> cheers,
>
> JJK / Jan Just Keijser
>
>
>
>
>
>
>
> --
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

[Openvpn-devel] VERY weird interaction between openvpn and opensc-pkcs11

[Jan Just Keijser]

hi all,

I just spent almost a day debugging a very weird interaction between 
OpenVPN 2.1 and opensc-pkcs11 :


Hardware:
a Feitian ePass smartcard with an Omnikey CardMan 3121 card reader

Software:
openvpn 2.1.3
opensc 0.12.0 (not officially released yet)
pkcs11-helper 1.07
linux 2.6.34 64bit kernel (fc13)

Here's what happens:

openvpn starts up, queries me for the PKCS11 prompt, connection is 
established alright.
When I look at the log file (with 'verb 99') I see that the pkcs11 
function __pkcs11h_forkFixup is called several times, with a different 
pid=%d value every time. This is bad, as it causes opensc-pkcs11 to 
reload the card every time (it calls C_Finalize then C_Initialize). This 
operation is very expensive.
During key renegotiation it gets even worse, as openvpn prompts me for 
the PIN again and connectivity is lost until I enter the PIN.


Now here's the weirdest part:

the __pkcs11h_forkFixup function is called after the invocation of an 
external program (e.g. /sbin/ip link , /sbin/ip/addr add etc). If I use

 script-security 2 system
the openvpn_execve function uses 'system()' calls to start these 
programs and the problem goes away !


So it seems that openvpn's openvpn_execve fork+waitpid function causes 
the program pid to change every time, triggering the reset of the pkcs11 
interface !


What shall we do about this?

cheers,

JJK / Jan Just Keijser

Re: [Openvpn-devel] [PATCH] Remove hardcoded path to resolvconf

[Jesse Young]

On Thu, Nov 11, 2010 at 00:25:03 +0100, David Sommerseth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 01/11/10 17:33, Jesse Young wrote:
> > Signed-off-by: Jesse Young 
> > ---
> >  contrib/pull-resolv-conf/client.down |5 +++--
> >  contrib/pull-resolv-conf/client.up   |5 +++--
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/contrib/pull-resolv-conf/client.down 
> > b/contrib/pull-resolv-conf/client.down
> > index 38c585b..05f2d4d 100644
> > --- a/contrib/pull-resolv-conf/client.down
> > +++ b/contrib/pull-resolv-conf/client.down
> > @@ -34,9 +34,10 @@
> >  # A horrid work around, from a security perspective,
> >  # is to run OpenVPN as root. THIS IS NOT RECOMMENDED. You have
> >  # been WARNED.
> > +PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin
> >  
> > -if [ -x /sbin/resolvconf ] ; then
> > -  /sbin/resolvconf -d "${1}"
> > +if type resolvconf >/dev/null 2>&1; then
> 
> Hi and thank you for your patch!

Hi David, Thanks for your comments. Hopefully, I will address them to
your satisfaction.

> Even though I do see that this approach is much cleaner.  Hardcoded
> paths is not ideal.  But I am not sure I like this way of test.  It
> works probably fine on up-to-date systems, but will it run on all most
> bash versions?  We must consider that there are some old systems with
> older bash installations which we might break.
> 
> I'd rather see a similar patch which checks the exit code instead of
> something more undefined like this approach.  Also for clarity in the
> code of what we expect or not.

I quickly ran this if statement in dash, bash --posix, and busybox's
implementation of sh, and all three worked as expected. In fact,
this is POSIX behavior.

See:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
> The if command shall execute a compound-list and use its exit status
> to determine whether to execute another compound-list.

Furthermore, I've explicitly changed the shell to /bin/dash and
verified that it works.  Also, this is the way dhcpcd determines if
resolvconf exists, from where I borrowed this code.

As for code clairity, I beleive this is a common sh idiom to branch
on the exit status of a command wile directing output to /dev/null. I
have personally seen it in many sh code.

Thanks,
Jesse

> kind regards,
> 
> David Sommerseth
> 
> 
> > +  resolvconf -d "${1}" -f
> >  elif [ -e /etc/resolv.conf.ovpnsave ] ; then
> ># cp + rm rather than mv in case it's a symlink
> >cp /etc/resolv.conf.ovpnsave /etc/resolv.conf
> > diff --git a/contrib/pull-resolv-conf/client.up 
> > b/contrib/pull-resolv-conf/client.up
> > index e81bd3a..b28d4d1 100644
> > --- a/contrib/pull-resolv-conf/client.up
> > +++ b/contrib/pull-resolv-conf/client.up
> > @@ -33,6 +33,7 @@
> >  # A horrid work around, from a security perspective,
> >  # is to run OpenVPN as root. THIS IS NOT RECOMMENDED. You have
> >  # been WARNED.
> > +PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin
> >  
> >  # init variables
> >  
> > @@ -86,8 +87,8 @@ fi
> >  out="# resolv.conf autogenerated by ${0} 
> > (${1})${nl}${dns}${nl}${ds}${domains}"
> >  
> >  # use resolvconf if it's available
> > -if [ -x /sbin/resolvconf ] ; then
> > -  printf "%s\n" "${out}" | /sbin/resolvconf -a "${1}"
> > +if type resolvconf >/dev/null 2>&1; then
> > +  printf "%s\n" "${out}" | resolvconf -p -a "${1}"
> >  else
> ># Preserve the existing resolv.conf
> >if [ -e /etc/resolv.conf ] ; then
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkzbKc8ACgkQDC186MBRfroIxgCdG+GexMR06qTHB4HvDsNtK1eK
> 10cAnikZC4ppKb62udCCR3Lx/5VeEzVi
> =6aYB
> -END PGP SIGNATURE-