Updates to the security document

This patch changes formatting and the DRBD shared secret details, and
adds master daemon socket details to the security doc.

Reviewed-by: imsnah

doc/security.rst

 Security in Ganeti
-~~~~~~~~~~~~~~~~~~
+==================
 
 Ganeti was developed to run on internal, trusted systems. As such, the
 security model is all-or-nothing.
@@ -17,21 +17,23 @@ cluster, there are no changes to the system.
 
 For a host that has been joined to the cluster, there are very important
 changes:
-  - The host will have its SSH host key replaced with the one of the
-    cluster (which is the one the initial node had at the cluster
-    creation)
-  - A new public key will be added to root's authorized_keys file, granting
-    root access to all nodes of the cluster. The private part of the key
-    is also distributed to all nodes. Old files are renamed.
-  - Communication between nodes is encrypted using SSL/TLS. A common
-    key and certificate combo is shared between all nodes of the cluster.
-    At this time, no CA is used.
-  - The Ganeti node daemon will accept RPC requests from any host within the
-    cluster with the correct certificate, and the operations it will do as a
-    result of these requests are:
-      - running commands under the /etc/ganeti/hooks directory
-      - creating DRBD disks between it and the IP it has been told
-      - overwrite a defined list of files on the host
+
+- The host will have its SSH host key replaced with the one of the
+  cluster (which is the one the initial node had at the cluster
+  creation)
+- A new public key will be added to root's authorized_keys file,
+  granting root access to all nodes of the cluster. The private part of
+  the key is also distributed to all nodes. Old files are renamed.
+- Communication between nodes is encrypted using SSL/TLS. A common key
+  and certificate combo is shared between all nodes of the cluster.  At
+  this time, no CA is used.
+- The Ganeti node daemon will accept RPC requests from any host within
+  the cluster with the correct certificate, and the operations it will
+  do as a result of these requests are:
+
+  - running commands under the /etc/ganeti/hooks directory
+  - creating DRBD disks between it and the IP it has been told
+  - overwrite a defined list of files on the host
 
 As you can see, as soon as a node is joined, it becomes equal to all
 other nodes in the cluster, and the security of the cluster is
@@ -39,10 +41,11 @@ determined by the weakest node.
 
 Note that only the SSH key will allow other machines to run random
 commands on this node; the RPC method will run only:
-  - well defined commands to create, remove, activate logical volumes,
-    drbd devices, start/stop instances, etc;
-  - run SSH commands on other nodes in the cluster, again well-defined
-  - scripts under the /etc/ganeti/hooks directory
+
+- well defined commands to create, remove, activate logical volumes,
+  drbd devices, start/stop instances, etc;
+- run SSH commands on other nodes in the cluster, again well-defined
+- scripts under the /etc/ganeti/hooks directory
 
 It is therefore important to make sure that the contents of the
 /etc/ganeti/hooks directory is supervised and only trusted sources can
@@ -53,27 +56,38 @@ Cluster issues
 
 As told above, there are multiple ways of communication between cluster
 nodes:
-  - SSH-based, for high-volume traffic like image dumps or for low-level
-    command, e.g. restarting the Ganeti node daemon
-  - RPC communication between master and nodes
-  - DRBD real-time disk replication traffic
+
+- SSH-based, for high-volume traffic like image dumps or for low-level
+  command, e.g. restarting the Ganeti node daemon
+- RPC communication between master and nodes
+- DRBD real-time disk replication traffic
 
 The SSH traffic is protected (after the initial login to a new node) by
 the cluster-wide shared SSH key.
 
 RPC communication between the master and nodes is protected using SSL/TLS
-encryption. Both the client and the server must have the cluster-widely
+encryption. Both the client and the server must have the cluster-wide
 shared SSL/TLS certificate and verify it when establishing the connection
 by comparing fingerprints. We decided not to use a CA to simplify the
 key handling.
 
-The DRBD traffic is not protected by encryption. DRBD does not support
-traffic encryption. It's therefore recommended to implement host-level
+The DRBD traffic is not protected by encryption, as DRBD does not
+support this. It's therefore recommended to implement host-level
 firewalling or to use a separate range of IP addresses for the DRBD
 traffic (this is supported in Ganeti) which is not routed outside the
-cluster. DRBD connections are protected from connecting to random other
-machines by using a shared secret exchanged via RPC requests when
-starting the device.
+cluster. DRBD connections are protected from connecting due to bugs to
+other machines, and from accepting connections from other machines, by
+using a shared secret, exchanged via RPC requests from the master to the
+nodes when configuring the device.
+
+Master daemon
+-------------
+
+The command-line tools to master daemon communication is done via an UNIX
+socket, whose permissions are reset to ``0600`` after listening but before
+serving requests. This permission-based protection is documented and works on
+Linux, but is not-portable; however, Ganeti doesn't work on non-Linux system at
+the moment.
 
 Remote API
 ----------