From: Jo Simoens Date: Thu, 19 May 2005 00:24:35 +0000 (+0000) Subject: some more typo hunting X-Git-Tag: Release-1.38.0~435 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=f65960585be07727fb22fdde3623fb8c3eb725eb;p=bacula%2Fdocs some more typo hunting --- diff --git a/docs/manual/security.tex b/docs/manual/security.tex index e9a9f5bc..65752797 100644 --- a/docs/manual/security.tex +++ b/docs/manual/security.tex @@ -61,7 +61,7 @@ access restrictions is the name you specify in the daemon configuration file. You must not use the {\bf twist} option in your {\bf /etc/hosts.allow} or it will terminate the Bacula daemon when a connection is refused. -Dan Languille has provided the following information on configuring and +Dan Langille has provided the following information on configuring and testing TCP wrappers with Bacula. If you read hosts\_options(5), you will see an option called twist. This @@ -78,7 +78,7 @@ ALL : ALL \ The libwrap code tries to avoid {\bf twist} if it runs in a resident process, but that test will not protect the first hosts\_access() call. This will -result in the prcess (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated +result in the process (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated if the first connection to their port results in the twist option being invoked. The potential, and I strees potential, exists for an attacker to prevent the daemons from running. This situation is eliminated if your @@ -183,7 +183,7 @@ access: delegated \index[general]{Running as non-root } \addcontentsline{toc}{subsection}{Running as non-root} -Security advice from Dan Languille: +Security advice from Dan Langille: It is a good idea to run daemons with the lowest possible privileges. In other words, if you can, don't run applications as root which do not have to diff --git a/docs/manual/stunnel.tex b/docs/manual/stunnel.tex index 8a3f62d3..6e4add91 100644 --- a/docs/manual/stunnel.tex +++ b/docs/manual/stunnel.tex @@ -8,7 +8,7 @@ \addcontentsline{toc}{section}{Using Bacula to Encrypt Communications to Clients} -Prior to verion 1.37, Bacula did not have built-in communications encryption. +Prior to version 1.37, Bacula did not have built-in communications encryption. Please see the TLS chapter if you are using Bacula 1.37 or greater. Without too much effort, it is possible to encrypt the communications @@ -29,10 +29,10 @@ stunnel version 4.04-4 on a Red Hat Enterprise 3.0 system. First, you must know that with the standard Bacula configuration, the Director will contact the File daemon on port 9102. The File daemon then contacts the Storage daemon using the address and port parameters supplied by the Director. -The standard port used will be 9103. This in the typical server/client view of +The standard port used will be 9103. This is the typical server/client view of the world, the File daemon is a server to the Director (i.e. listens for the Director to contact it), and the Storage daemon is a server to the File -daemon. +daemon. \subsection*{Encryption} \index[general]{Encryption } @@ -40,15 +40,15 @@ daemon. The encryption is accomplished between the Director and the File daemon by using an stunnel on the Director's machine (server) to encrypt the data and to -contact a stunnel on the File daemon's machine (client), which decrypts the +contact an stunnel on the File daemon's machine (client), which decrypts the data and passes it to the client. Between the File daemon and the Storage daemon, we use an stunnel on the File daemon's machine to encrypt the data and another stunnel on the Storage daemon's machine to decrypt the data. -As a consequence, there are actually four copies of stunnel running, two on -server and two on client. This may sound a bit complicated, but it really +As a consequence, there are actually four copies of stunnel running, two on the +server and two on the client. This may sound a bit complicated, but it really isn't. To accomplish this, we will need to construct four separate conf files for stunnel, and we will need to make some minor modifications to the Director's conf file. None of the other conf files need to be changed. @@ -113,16 +113,16 @@ See below for how to create a self-signed certificate. To simplify things a bit, let's for the moment consider only the data channel. That is the connection between the File daemon and the Storage daemon, which takes place on port 9103. In fact, in a minimalist solution, this is the only -connection needs to be encrypted, because it is the one that transports your +connection that needs to be encrypted, because it is the one that transports your data. The connection between the Director and the File daemon is simply a control channel used to start the job and get the job status. Normally the File daemon will contact the Storage daemon on port 9103 -(supplied by the Director), so we need a stunnel that listens on port 9103 on +(supplied by the Director), so we need an stunnel that listens on port 9103 on the File daemon's machine, encrypts the data and sends it to the Storage daemon. This is depicted by Stunnel 2 above. Note that this stunnel is listening on port 9103 and sending to server:29103. We use port 29103 on the -server because if we sent the data to port 9103, it would go directly to the +server because if we would send the data to port 9103, it would go directly to the Storage daemon, which doesn't understand encrypted data. On the server machine, we run Stunnel 4, which listens on port 29103, decrypts the data and sends it to the Storage daemon, which is listening on port 9103. @@ -176,7 +176,7 @@ well. \addcontentsline{toc}{subsection}{config Files for stunnel to Encrypt the Data Channel} -In the diagram above, we see above Stunnel 2 that we stunnel-fd2.conf on +In the diagram above, we see above Stunnel 2 that we use stunnel-fd2.conf on the client. A pretty much minimal config file would look like the following: \footnotesize diff --git a/docs/manual/tls.tex b/docs/manual/tls.tex index 15617ee1..046fc0f9 100644 --- a/docs/manual/tls.tex +++ b/docs/manual/tls.tex @@ -24,7 +24,7 @@ terms refer to the accepting and initiating peer, respectively. Diffie-Hellman anonymous ciphers are not supported by this code. The use of DH anonymous ciphers increases the code complexity and places explicit trust upon the two-way Cram-MD5 implementation. Cram-MD5 is -subject to known plaintext attacks, and is should be considered +subject to known plaintext attacks, and it should be considered considerably less secure than PKI certificate-based authentication. Appropriate autoconf macros have been added to detect and use OpenSSL