add some security notes to the master/slave documentation --niko

1 files changed, 16 insertions, 3 deletions

diff --git a/doc/smokeping_master_slave.pod b/doc/smokeping_master_slave.pod
index 009a6c2..bd3b41f 100644
--- a/doc/smokeping_master_slave.pod
+++ b/doc/smokeping_master_slave.pod
@@ -33,9 +33,9 @@ of probing it connects to the master again to deliver the results.
 If the assignment for a slave changes, the master will tell the slave after
 the slave has delivered its results.
 
-The master and the slaves sign their messages by supplying an md5 hash of the
-message appended with a shared secret. Optionally the whole communication
-can run over ssl.
+The master and the slaves sign their messages by supplying an HMAC-MD5
+code (RFC 2104) of the message and a shared secret. Optionally the whole
+communication can run over ssl.
 
     [slave 1]     [slave 2]      [slave 3]
         |             |              |
@@ -119,6 +119,19 @@ F</tmp/smokeping.$USER.cache>.
              --cache-dir=/var/smokeping/ \
              --shared-secret=/var/smokeping/secret.txt
 
+=head1 SECURITY CONSIDERATIONS
+
+The master effectively has full access to slave hosts as the user the
+slave smokeping instance is run as. The configuration is transferred as
+Perl code that is evaluated on the slave. While this is done inside a
+restricted C<Safe> compartment, there are various ways that a malicious
+master could use to embed arbitrary commands in the configuration and
+get them to run when the slave probes its targets.
+
+The strength of the shared secret is thus of paramount importance. Brute
+forcing the secret would enable a man-in-the-middle to inject a malicious
+new configuration and compromise the slave.
+
 =head1 COPYRIGHT
 
 Copyright (c) 2007 by Tobias Oetiker, OETIKER+PARTNER AG. All right reserved.