diff options
authorYorhel <>2012-03-22 19:27:54 +0100
committerYorhel <>2012-03-22 19:27:54 +0100
commitb07e323586e7400bad72abaaf2ea75340cba9ff9 (patch)
parent7cdb326621e532727e1faff6085b90ac39ffca7a (diff)
proto: Documented some simple ideas on how to do securityHEADmaster
1 files changed, 58 insertions, 0 deletions
diff --git a/proto.pod b/proto.pod
index bd3f2a0..74d6735 100644
--- a/proto.pod
+++ b/proto.pod
@@ -268,3 +268,61 @@ Message type 7. Second element is the $tid, encoded as a number.
+=head1 Stream protocols and security
+This section is purely informative and only lists some recommendations, it is
+not a specification that implementations must follow.
+The above protocol does not specify any security, it assumes that this is
+handled in the lower protocol that takes care of setting up the stream. Here I
+present a few recommendations and techniques for adding this security. These
+assume that there is at least one process in the Tanja network that runs on a
+UNIX-like machine (ideally this process also runs the sessions that you wish to
+communicate with, but it could just as well play the role of a tuple router or
+=head2 UNIX sockets
+Any process that accepts incoming connections for linking with Tanja nodes
+(let's call this a I<server>), should do this with a UNIX listen socket. This
+way, only processes on the local machine with the correct user permissions will
+be able to connect. There is no need for additional security within the
+application layer in this setup: As soon as a client connects to the UNIX
+socket, the link protocol is initiated and the handshake starts.
+=head2 SSH
+The above mentioned servers only accept connections from the local machine. To
+also allow connections from remote machines, the server (not the server
+process, but the system it runs on) should be configured to accept SSH
+connections for a certain user that has the right permissions to connect to the
+UNIX socket. This does not necessarily have to be the same user as the one that
+runs the server process, as long as it can connect to the local socket.
+Processes that wish to connect to the remote server can then use SSH to log in
+remotely, connect to the UNIX socket and then somehow forward this connection
+over SSH. Unfortunately, the ubiquitously available OpenSSH implementation does
+not seem to offer a method for forwarding UNIX sockets, but it is still
+possible to do this by remotely executing a command that connects to the UNIX
+socket and forwards the connection to standard I/O.
+If the server has the I<socat> utility installed, then the remote command is as
+ socat - UNIX-CONNECT:/path/to/local/server.socket
+Unfortunately, socat is not installed by default on most current UNIX systems.
+If the server has Perl installed (which is very likely), then the following
+perl (wannabe) one-liner can be used as well: (Broken over multiple lines for
+formatting purposes, but it really is a single command).
+ perl -MIO::Socket -MIO::Select -e '$|=1;$u=IO::Socket::UNIX->new(shift)
+ ||exit;$u->autoflush(1);$s=IO::Select->new(STDIN);$s->add($u);
+ while(@r=$s->can_read){for(@r){$b="";sysread($_,$b,10240)||exit;
+ print{$_==$u?STDOUT:$u}$b;}}' /path/to/local/server.socket
+Suggestions for a more elegant solution are highly appreciated.