Remove references to beanstalkd

1 files changed, 10 insertions, 16 deletions

diff --git a/SECURITY b/SECURITY
index 42ffc18..c6bd1f5 100644
--- a/SECURITY
+++ b/SECURITY
@@ -4,12 +4,12 @@
 custodian-enqueue
 -----------------
 
-We open a single named file so that we may parse tests.  There seems no harm in this,
-because the user must have permission to parse the file.
+We open a single named file so that we may parse tests.  There seems no harm in
+this, because the user must have permission to parse the file.
 
-To successfully enqueue jobs that have been parsed the user must be able to talk to the
-beanstalkd queue - but this happens over TCP, so there is no need to run the parsing
-tool as root, and this is generally discouraged.
+To successfully enqueue jobs that have been parsed the user must be able to
+talk to the queue - but this happens over TCP, so there is no need to run the
+parsing tool as root, and this is generally discouraged.
 
 Conclusion: The enqueuing process contains no security risks.
 
@@ -30,8 +30,7 @@ So the following configuration file snippet potentially allows a command to be e
 
     $(/home/steve/hg/custodian/exploit.sh) must ping otherwise "Owned".
 
-Given that anybody who can talk to the beanstalkd server can submit jobs we cannot rely on catching
-this solely in the parser.
+Given that anybody who can talk to the queue can submit jobs we cannot rely on catching this solely in the parser.
 
 For the moment we've solved the case of the ping-exploitation, by validating
 that hostnames passed to the multi-ping command match ^[a-z0-9.-]$ - in both
@@ -41,8 +40,7 @@ possible forms:
 
   * Ensure the hostname is valid before adding the job to the queue.
 
-We are careful to run the system command in the Ruby array-format, which will bypass shell
-exploitation.
+We are careful to run the system command in the Ruby array-format, which will bypass shell exploitation.
 
 Conclusion: There are no obvious security concerns in the dequeuing process.
 
@@ -51,20 +49,16 @@ Conclusion: There are no obvious security concerns in the dequeuing process.
 General
 -------
 
-We pull arbitrary jobs from the queue, and it is possible an attacker could add malicious
-entries.
-
-We could sign tests to prevent trojan malformed lines from being processed, but this is
-not yet done.  (It isn't obvious if this would be a sensible addition either.)
+We pull arbitrary jobs from the queue, and it is possible an attacker could add malicious entries.
 
+We could sign tests to prevent trojan malformed lines from being processed, but this is not yet done.  (It isn't obvious if this would be a sensible addition either.)
 
 
 
 Anything else?
 --------------
 
-DoS attacks seem likely - the simple case would be to stuff the queue with sufficiently many
-"bogus" jobs that "real" jobs are never completed.
+DoS attacks seem likely - the simple case would be to stuff the queue with sufficiently many "bogus" jobs that "real" jobs are never completed.