strongswan/src/frontends/osx
Tobias Brunner f6aafb3005 Fixed some typos, courtesy of codespell
Main change is the conversion from the British cancelling/-ed to the
American canceling/-ed.
2021-06-25 11:32:29 +02:00
..
charon-xpc Fixed some typos, courtesy of codespell 2021-06-25 11:32:29 +02:00
strongSwan Fixed some typos, courtesy of codespell 2018-02-13 12:19:54 +01:00
strongSwan.xcodeproj libhydra: Remove empty unused library 2016-03-03 17:36:11 +01:00
.gitignore xpc: add Xcode project for a charon controlled through XPC 2013-07-18 12:17:54 +02:00
README.md osx: Include eap-gtc plugin in build instructions 2015-03-16 09:27:18 +01:00

README.md

strongSwan OS X App

Introduction

The strongSwan OS X App consists of two components:

  • A frontend App to configure and control connections (under strongSwan)
  • A privileged helper daemon, controlled using XPC (under charon-xpc)

The privileged helper daemon gets installed automatically using SMJobBless functionality on its first use, and gets started automatically by Launchd when needed.

charon-xpc is a special build linking statically against strongSwan components.

charon-xpc and the App sources are currently not part of the official strongSwan distribution. Build the charon-xpc tarball with:

git archive -o osx-sources-$(grep AC_INIT configure.ac | \
                            cut -d '[' -f3 | cut -d ']' -f1).tar.bz2 \
    HEAD src/frontends/osx

Building strongSwan

Before building the Xcode project, the strongSwan base tree must be built using a monolithic and static build. This can be achieved on OS X by using:

CFLAGS="-O2 -g -Wall -Wno-format -Wno-pointer-sign -Wno-deprecated-declarations" \
./configure --enable-monolithic --disable-shared --enable-static \
    --disable-defaults \
    --enable-openssl --enable-kernel-libipsec --enable-kernel-pfroute \
    --enable-eap-mschapv2 --enable-eap-identity --enable-eap-md5 \
    --enable-eap-gtc --enable-pkcs1 --enable-socket-default --enable-osx-attr \
    --enable-xauth-generic --enable-gcm --enable-ccm --enable-ctr \
    --enable-keychain --enable-nonce --enable-charon \
    --enable-ikev1 --enable-ikev2

followed by calling make (no need to make install).

Building charon-xpc using the Xcode project yields a single binary without any non OS X dependencies. The strongSwan target in the same project builds the App and integrates charon-xpc for the deployment.

Both charon-xpc and the App must be code-signed to allow the installation of the privileged helper. By default both targets use the Developer ID: * wildcard to use the first usable code signing identity. Both the App and charon-xpc require a hardcoded certificate subject under strongSwan/strongSwan-Info.plist respectively charon-xpc/charon-xpc-Info.plist. Update the org.strongswan.charon-xpc SMPrivilegedExecutables in the App and SMAuthorizedClients in charon-xpc with your code signing certificate identity.

XPC application protocol

charon-xpc provides a Mach service under the name org.strongswan.charon-xpc. Clients can connect to this service to control the daemon. All messages on all connections use the following string dictionary keys/values:

  • type: XPC message type, currently either
    • rpc for a remote procedure call, expects a response
    • event for application specific event messages
  • rpc: defines the name of the RPC function to call (for type = rpc)
  • event: defines a name for the event (for type = event)

Additional arguments and return values are specified by the call and can have any type. Keys are directly attached to the message dictionary.

On the Mach service connection, the following RPC messages are currently defined:

  • string version = get_version()
    • version: strongSwan version of charon-xpc
  • bool success = start_connection(string name, string host, string id, endpoint channel)
    • success: TRUE if initiation started successfully
    • name: connection name to initiate
    • host: server hostname (and identity)
    • id: client identity to use
    • channel: XPC endpoint for this connection

The start_connection() RPC returns just after the initiation of the call and does not wait for the connection to establish. Nonetheless does it have a return value to indicate if connection initiation could be triggered.

The App passes an (anonymous) XPC endpoint to start_connection(). If the call succeeds, charon-xpc connects to this endpoint to establish a channel used for this specific IKE connection.

On this channel, the following RPC calls are currently defined from charon-xpc to the App:

  • string password = get_password(string username)
    • password: user password returned
    • username: username to query a password for

And the following from the App to charon-xpc:

  • bool success = stop_connection()
    • success: TRUE if termination of connection initiated

The following events are currently defined from charon-xpc to the App:

  • up(): IKE_SA has been established
  • down(): IKE_SA has been closed or failed to establish
  • child_up(string local_ts, string remote_ts): CHILD_SA has been established
  • child_down(string local_ts, string remote_ts): CHILD_SA has been closed
  • log(string message): debug log message for this connection