TESLA 0.4

by Jon Salz <jsalz@mit.edu>, Alex Snoeren <snoeren@lcs.mit.edu>

TESLA is a generalized architecture for the development and deployment of session-layer services. It uses dynamic library interposition to trap applications' network I/O calls, routing them through handlers that provide services such as compression, encryption, transparent SOCKS proxying, traffic rate shaping, and end-to-end flow migration.

TESLA is known to work on Linux and FreeBSD (tested on RedHat Linux 7.3 and FreeBSD 4.6-STABLE) and may work on other systems with minimal modification.

Availability

• i386 RPM for RedHat Linux 7.3: tesla-0.4-1.i386.rpm
• Source RPM for RedHat Linux 7.3: tesla-0.4-1.src.rpm
• Tarball: tesla-0.4.tar.gz

Using TESLA

To use TESLA, use the "tesla" wrapper script to invoke applications. To enable a particular handler, use a plus sign followed by the handler name, followed by flags for that handler (if any). Following this, provide the command and arguments you wish to run. For example, to run telnet with the SOCKS and "log" handlers:

tesla +socks -host=192.168.0.15 -port=1080 \
    +log -all telnet beacon

Each handler flag is either Boolean, with no argument (e.g., -all) or is followed by an equal sign and a value (e.g., -host=192.168.0.15).

Note that handler order is important: in the above example, the log handler will record bytes actually written to/from the network (i.e., including SOCKS protocol stuff) whereas if +log were before +socks, it would record bytes written to/from the application (i.e., not including SOCKS protocol stuff).

You can obtain usage information for handlers by not providing any command to run:

tesla +socks +log

The -d argument (before any handlers) turns some debugging messages on (you can specify a number after -d, up to -d4, to increase the debugging level further). The -f argument (-ffile) allows you to specify the file to direct these messages to (if unspecified stderr is used). Debugging messages are probably not of much use unless you are a TESLA developer!

Setuid Applications

TESLA provides experimental support for applications which are setuid root (but not setuid anything-else). TESLA is enabled only when such an application drops its root privileges.

This is not heavily tested and may be a security problem (remember that bug that was hanging around suidperl for a year or two?), so caveat user!

Setuid support requires suidperl to be installed on your system (since the tesla wrapper is written in Perl). In addition you must use make install-suid rather than make install when building TESLA.

Building and Installing TESLA

To build and install TESLA:

autoconf
./configure
make
make install ; # As superuser

Note that if you have any handlers already installed (e.g., from an older version of TESLA) you must rebuild the handlers as well, or the teslamaster binary may fail to operate correctly.

This will install the following components:

$BINDIR/tesla

A wrapper script that can be used to invoke TESLA. It adds libtesla.so to the LD_PRELOAD environment variable and passes configuration parameters to the handlers (run "tesla -h") for an example.

$LIBDIR/tesla/libtesla.so

The shared library which traps applications' network I/O calls.

$LIBDIR/tesla/teslamaster

The program that libtesla.so spawns, responsible for running any enabled handlers. (This is entirely internal to TESLA; you'll never have to run it.)

$LIBDIR/tesla/handlers/*.o

Code implementing The various available handlers. You can add a handler to TESLA by compiling it, placing the resulting object file here, and rerunning tesla-rebuild (below).

$INCLUDEDIR/tesla/*.{h|hh}

#include files for building handlers.

$BINDIR/tesla-rebuild

A script which relinks the $LIBDIR/teslamaster.a file, and any handlers in $LIBDIR/tesla/handlers/*.o, to regenerate the teslamaster binary. Run this script after installing/deinstalling handlers.