Bug 815127

This is a openswan bug, change the component...

Created attachment 584067 [details]
Patches contrib/pam.d/pluto and programs/pluto/xauth.c

Thanks for the patch. I merged it in, apart from the casts.

Dear Paul,

A reproach I can make to many Opensource codes is that they gcc compile with -Wall only preventing the codes to be even more robust if they simply add -Werror to the compile-time option.

This simple fact makes many source codes not have a professional look and are to often be reworked upon when a non gcc compiler is used on another operating system platform.

Also one can wonder about the trust upon a software one can have when the build process shows compile-time messages. The impression is that one has to cross one's finger so that the code actually works as promised. This is not counting the runtime errors or poor implementations which are only visible thanks to thorough tests that most developers do not take enough time upon.

So your "apart casts" is definitely not an attitude I would have adopted provided I were in your position at Red Hat.

Also if you carefully read my paper in this Openswan wish report to fully support PAM authentication (URL link above) and especially the chapter starting with "Another question from the author to the Openswan maintainers", the pthread_create with a detach pthread attribute for only calling do_authentication brings unneeded complexity as proved by tests. Any useless code may be subject to bugs. So I think it is time to consider much simplifying the corresponding code. I also wonder if more deeper Openswan xauth.c code review whether the HAVE_THREADS compile-time conditional in Makefile.inc which relevant extract is reproduced hereafter:
ifeq ($(USE_XAUTHPAM),true)
HAVE_THREADS=true
endif
reveals absolutely necessary and the simpler and more direct USE_XAUTHPAM should not be sufficient to correctly address the problem.

Simplifying as much as possible this aspect may further help the developers envision a runtime option for example set in /etc/ipsec.conf configuration file so that PAM authentication or the more classic Openswan authentication can selectable at Openswan initialization time by anyone downloading and running a pre-configured Red Hat made Openswan RPM.

Yours sincerely,
Philippe Vouters (another Wouters but with a V instead of W)

Created attachment 613231 [details]
Feasibility test patch to Openswan

This patch modifies openswan-2.6.38/Makefile.inc, openswan-2.6.38/contrib/pam.d/pluto,openswan-2.6.38/programs/pluto/xauth.c. Sorry Paul ! the modifications to xauth are NOT "Apart cast".

I have demonstrated with this attached patch that I have able to establish a VPN tunnel between my Shrew VPN client on Windows 7 and Openswan on my Linux Fedora 17 meanwhile PAM authenticating using my Fedora Unix account password.

So HAVE_THREADS is not compulsary when USE_XAUTHPAM = true.

This forward means:

1/ that all #ifdef USE_XAUTHPAM #else #endif may be easily configured in /etc/ipsec.conf via a global variable of type enumerated. For example : typedef enum {NONE=0, MD5=1, PAM=2} authentication_t;

2/ most if not all #ifdef HAVE_THREADS may perhaps be turned to #if 0. This should opens the door for even more simplifications to the Openswan code.

Yours sincerely,
Philippe

Created attachment 613361 [details]
Used this perl code to prove #ifdef HAVE_THREADS can be safely replaced by #if 0

To use this Perl attached code in the Openswan Version 2.6.38 context, I executed it with the command:
[~/]$ perl test_perl_glob.pl openswan-2.6.38 \\.c\$ "#ifdef HAVE_THREADS" "#if 0"

This command above replaces in every .c source file of openswan-2.6.38 directory tree each occurence of #ifdef HAVE_THREADS by #if 0

Dear Red Hat support,

I now prove by successfully establishing a VPN tunnel using Shrew VPN Client on Windows 7 and Openswan 2.6.38 as the VPN server on my Linux Fedora 17 using PAM authentication that all the #ifdef HAVE_THREADS can safely be replaced by #if 0. 

I even got a very positive side effect. When previously experiencing frequent "no dhcp respsonse from gateway" reported by the Shrew VPN Client, my very first attempt to VPN connect has been the successful one. This needs confirmation with more trials but this "no dhcp repsonse from gateway" too frequently reported by Shrew VPN client seems to be bound with too much Openswan useless code running on the Linux side.

So Openswan 2.6.38 at least on Linux and acting as a VPN server can be source simplified much easing its code maintenance and more easing a /etc/ipsec.conf authentication runtime configuration. This is along with the previous suggestion of replacing each #ifdef USE_XAUTHPAM #else #endif occurence by a runtime appropriate if (condition) {} else {} sequence.

This will allow people to install future openswan packages (.rpm or .deb) with more transparent use on various Linux distributions and not depend upon Openswan source code downloads and local rebuilds. With PAM authentication selectable in a configuration file as everything looks working really fine. Behind PAM authentification are the Unix, OpenLDAP and Microsoft Active Directory authentication. Active Directory athentication looks possible through OpenLDAP via an SASL mechanism. Active Directory authentication through OpenLDAP is what describes a Linagora document in French.

Yours truly,
Philippe Vouters (Fontainebleau/France)

Hi Philippe,

I never intended to say the casts were wrong, but that they needed looking into. Casting from one type to another usually indicates hiding the real problem, and I just meant to relay to you that I wanted to look into the underlying problem so the casts could be avoided.

I will look at your patches regarding threads. You are fully correct that openswan should not be using threads, as it is using a "dodged" state machine. 

The reason XAUTH (and some other code such as CRL fetching) uses threads was because the people who submitted those patches did not understand the pluto daemon model. The reason they used threads was to ensure potential slow work (fetching a CRL or doing a user authentication that might require some network connection, eg a PDC) would not block the pluto IKE daemon for too long. The proper method would be to convert these to a "pluto helper" and scheduling an EVENT_EXPIRE.

Again, I'll be looking at your patches carefully for integration. I'd love to be able to remoev threads from pluto entirely, so thank you for your work towards that goal!

Created attachment 615286 [details]
Openswan 2.6.38 - Patch to have runtime selectable VPN clients authentications

Added in connections the recognition of authentication={md5 | pam} inside conns. It defaults to md5 to keep upward compatibility. Actual configuration example:
conn Philippe_XAUTH_PSK_DHCP
     authby=secret
     leftxauthserver=yes
     rightxauthclient=yes
     rightid=@#0x4047726f757056504e
     aggrmode=yes
     also=DHCP_RIGHT_IP
     authentication=pam

conn DHCP_RIGHT_IP
     pfs=yes
     type=tunnel
     dpddelay=30
     dpdtimeout=120
     dpdaction=clear
     left=%defaultroute
     leftnexthop=%defaultroute
     leftprotoport=udp/bootps
     leftupdown="ipsec _updown --route yes 2>&1 >/tmp/_updown.txt"
     right=%any
     rightprotoport=udp/bootps
     keyingtries=3
     rekey=no
     auto=add


conn FIXED_RIGHT_IP 
     pfs=yes
     type=tunnel
     dpddelay=30
     dpdtimeout=120
     dpdaction=clear
     left=%defaultroute
     leftnexthop=%defaultroute
     leftsubnet=0.0.0.0/0
     leftupdown="ipsec _updown --route yes 2>&1 >/tmp/_updown.txt"
     right=%any
     rightsubnet=vhost:%no,%priv
     keyingtries=3
     rekey=no
     auto=add

Also USE_XAUTHPAM depends on OS. Currently set true on Linux.
All #ifdef HAVE_THREADS are replaced by #if 0.

Hi Paul,

My last patch is guaranted to work under the following conditions:
1/ Linux Fedora 17 operating system.
2/ Patched (last patch submitted Red Hat) Openswan 2.6.38 acting as a VPN server
3/ Windows/Linux Shrew VPN clients

For full information, refer to http://vouters.dyndns.org/tima/Linux-Openswan-Shrew_VPN_Client-PAM-Adding_XAUTH_PAM_support_to_Openswan-Testing_with_Shrew.html

As per this URL at http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/
PAM authentication ought to also be available on FreeBSD 5.x and 4.x and Solaris.

So in Openswan-x.y.z/Makefile.inc, one should also add:

ifeq($(OS),FreeBSD)
USE_XAUTHPAM=true
endif
ifeq($OS),Solaris)
USE_XAUTHPAM=true
endif

after:

ifeq($(OS),Linux)
USE_XAUTHPAM=true
endif

as well as adding any operating operating system supporting the Pluggable Authentication Modules.

Patch untested under this condition: Openswan acting as a VPN client.

Yours truly,
Philippe

Hi Paul,

This VPN configuration described in this below URL works also fine with my last patched Openswan 2.6.38:
http://vouters.dyndns.org/tima/Linux-Openswan-Setting_up_an_Intranet_VPN_with_Windows_7.html

So I cannot yet notice any brought in regressions with all the #ifdef HAVE_THREADS replaced by #if 0.

I did notice some CYGWIN preprocessor macros in Openswan 2.6.38 source code. My next step will be to try an Openswan build and, if it builds, runtime test it under Windows/Cygwin. In this Windows/Cygwin environment, my goal is to execute Openswan as a VPN client. My Openswan VPN server will be kept on my Linux Fedora 17 computer.

Best regards,
Philippe

Openswan has not been tested in a while for cygwin. 


The issue with removing threads is that the main pluto process will not be able to launch the xauth system pam verification in a thread. This operation is blocking, so it prevents pluto from doing IKE with other connections while your one connection is getting authenticated. So you will not see any issues when using a single connection. But if you mix non-pam authenticated and pam authenticated tunnels, the pam authentication could block the non-pam connections.

In theory, on a gateway with subnet-subnet tunnels, and enduser tunnels, A failing pam backend auth could block the subnet-subnet tunnels from establishing.

The threads used by pam and crl fetching have to be rewritten as "pluto helpers", like the DNS and crypto helpers. Once that is done, threads can be removed completely from openswan

Dear Paul,

As it seems my privately sent email did not reach you, I'd like you to comment on this wordings of mine in a related paper on my Web site. I believe I do not denature your Openswan real skills you base your opinion onto and you so far expressed:

<NOTE>
This openswan patch replaces all #ifdef HAVE_THREADS by #if 0. You may incur
Openswan being blocked during a TCP/IP C connect timeout with the LDAP server
not answering as LDAP uses TCP/IP. If you implement an Active Directory
authentication over LDAP, and the Windows node takes time to respond to LDAP,
Openswan will be blocked during all the PAM authentication attempt. If you mix
PAM including LDAP authentications and non-PAM authentications, the non-PAM
authentication will be blocked during the PAM authentication time. The same is
true with non-PAM authentications which uses the /etc/ipsec.d/passwd file and
this file being stored onto a slow medium. If this file is stored on a Storage
Architecture Network (SAN) or Network Architecture Strorage (NAS) or a remote NFS disk, you will incur the exact same Openswan blocking symptoms if the SAN or the NAS or the NFS server are slow to respond.

In conclusion, make sure all kind of possible authentications are fastly
responding before applying such patch. The Openswan developers are aware of
the problem and intend to replace all the pthreads calls by Openswan existing
internal mechanisms known as "pluto helpers"."pluto helpers" are already
implemented in the Openswan DNS and crypto current handling. With these helpers,
Openswan will more ressemble to a state machine which is the idea behind the
original implementation.
</NOTE>

Thank you so much in advance to give me your expert opinion onto. Note that I am ever trying to my best. For your knowledge, anything I publicly document is subject to changes as soon as I get even more insight in a subject I study. The absolute truth for me are NOT opinions, but facts which can be verified.

With my very warmest regards to you.
Philippe

Created attachment 621003 [details]
Openswan 2.6.38 6 - patch - Successfully tested with two simultaneous Shrew clients

I tested this last patch with these conditions (different uri tested in /etc/pam_ldap.conf) using two simulteanous Shrew DHCP'ed clients.

$ sudo cat /etc/ipsec.d/vouters.conf
conn Philippe_XAUTH_PSK_DHCP
     authby=secret
     leftxauthserver=yes
     rightxauthclient=yes
     rightid=@#0x4047726f757056504e
     aggrmode=yes
     also=DHCP_RIGHT_IP
     xauthby=pam
        
conn DHCP_RIGHT_IP
     pfs=yes
     type=tunnel
     dpddelay=30
     dpdtimeout=120
     dpdaction=clear
     left=%defaultroute
     leftnexthop=%defaultroute
     leftprotoport=udp/bootps
     leftupdown="ipsec _updown --route yes 2>&1 >/dev/null"
     right=%any
     rightprotoport=udp/bootps
     keyingtries=3
     rekey=no
     auto=add

conn FIXED_RIGHT_IP 
     pfs=yes
     type=tunnel
     dpddelay=30
     dpdtimeout=120
     dpdaction=clear
     left=%defaultroute
     leftnexthop=%defaultroute
     leftsubnet=0.0.0.0/0
     leftupdown="ipsec _updown --route yes 2>&1 >/dev/null"
     right=%any
     rightsubnet=vhost:%no,%priv
     keyingtries=3
     rekey=no
     auto=add

$ sudo cat /etc/pam_ldap.conf
base dc=vouters,dc=dyndns,dc=org
binddn cn=admin,dc=vouters,dc=dyndns,dc=org
bindpw secret
pam_filter objectclass=inetOrgPerson
pam_login_attribute uid
pam_password clear
bind_timelimit 120
bind_policy hard 
timelimit 120
# This does not seem to be handled by OpenLDAP.
#restart no
ssl no
tls_cacertdir /etc/openldap/cacerts

# Existing LDAP server - This one authenticates
uri ldap://127.0.0.1/
# DSL box gateway (no answer) - This one causes multiple TCP/IP SYN
# request until it times out. Generates "session terminated by gateway" if 
# bind_timelimit is set to 120 or "user authentication error" 
# if bind_timelimit is set to 2
#uri ldap://192.168.1.1/
# responding remote IP address but no LDAP listening port causing
# TCP/IP RST flag set. Generates a "user authentication error"
#uri ldap://213.41.97.81/
# inexistant local network IP address (ARP query timeout). Generates
# a "user authentication error"
#uri ldap://192.168.1.10/

$ sudo cat /etc/pam.d/pluto
#%PAM-1.0
auth       sufficient   /lib/security/pam_ldap.so
auth       required     /lib/security/pam_unix_auth.so use_first_pass
account    sufficient   /lib/security/pam_ldap.so
account    required     /lib/security/pam_unix_acct.so
password   required     /lib/security/pam_cracklib.so retry=3
password   sufficient   /lib/security/pam_ldap.so
password   required     /lib/security/pam_unix.so try_first_pass

I hope that one day I shall be able to test a Microsoft Active Directory PAM authentication via an SASL daemon. At first glance, only OpenLDAP and eventually /etc/pam_ldap.conf would need reconfiguration. However this should not change the problem regarding PAM authentication through Openswan.

Note that this patch currently defines XAUTH_USEPAM only for the Linux operating system. More operating systems supporting PAM authentication may be added over time (refer to Makefile.inc).

For full information, refer to the latest update of my Web document at http://vouters.dyndns.org/tima/Linux-Openswan-Shrew_VPN_Client-PAM-Adding_XAUTH_PAM_support_to_Openswan-Testing_with_Shrew.html

Best regards to everyone.
Philippe Vouters (Fontainebleau/France)

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This has been fixed in libreswan, thanks to a lot of hard work from Philippe to fix the the threads issue. As libreswan is replacing openswan in Fedora, I'm moving this to RELEASE_PENDING for libreswan, as "yum update" will bring this support to fedora (currently in rawhide and f18)