Added information about root passwords, which machines should share them,

and which should not. Also filled in a few minor omissions in other sections.

*** Please comment ***

doc/security.txt

@@ -10,7 +10,9 @@ be done to enhance it:
 2) Firewalling:
   2.1) Block outgoing connections from testbed nodes to the CS network
     - This is because something on this network may have (misguided)
-    trust in them (especially paper/plastic)
+    trust in them (especially paper/plastic) (note: This may be less
+    important when we're on our own subnets, as CS shouldn't be trusting
+    them at all)
   2.2) May want to block outgoing connections on specific ports to all
     IPs - for example, the SMTP port, to prevent people from using
     testbed nodes as spam mailhubs. Then again, this may be too
@@ -19,24 +21,44 @@ be done to enhance it:
 3) Filesystems:
   3.1) Home directories should be exported only to nodes currently
     running experiments that the user is involved in (will be secure
-    because of 1.1)
+    because of item 1.1)
   3.2) Home directories on Plastic should be mounted with the 'nosuid'
     and 'nodev' options on plastic and paper - users could, on their
     test nodes, create set-uid root programs, or make device nodes
     that they are allowed to read an write to.
   3.3) Remove suidperl binary on plastic (doesn't get installed on
     latest FreeBSD versions anyway) - See FreeBSD mount manpage for
-    reason. Related to 3.2
+    reason. Related to item 3.2
   3.4) All testbed nodes, and plastic (any maybe paper too?) should
     NOT be able to mount our NFS server(s) or CS's. Could happen
     either through firewalling or rules on the NFS servers.
     
-4) Policies:
-  4.1) Flux'ers accounts on plastic and testbed nodes should not have
+4) Passwords
+  4.1) Testbed node root passwords are problematic. Testbed nodes
+    should definitely have a root password that is not used anywhere
+    else. Maybe they should have no root password (an invalid hash,
+    not a blank one) and just trust paper to login as root via ssh.
+    If someone who has local_root for a project crack a node's root
+    password, then they can get root on other project's nodes, or the
+    same node later, when another project owns it. Then again, maybe 
+    we don't need to set our security stanards quite that high.
+  4.2) It would be reasonable to share a root password between paper
+    and the Cisco's. Having root on paper will mean that someone will
+    have access through SNMP, etc. to the ciscos, and having the
+    enable passwork to the ciscos will allow someone to bypass our
+    protections in section 1 and spoof paper, so they are essentailly
+    equivalent.
+  4.3) Plastic should have a unique root password - we don't want to
+    have it the same as the testbed nodes (easy access to crack), but
+    we want to make root compromise of plastic not lead to the root
+    compromise of paper.
+
+5) User policies:
+  5.1) Flux'ers accounts on plastic and testbed nodes should not have
     stanard passwords (people may be able to get encrypted string and
     crack)
-  4.2) No accounts on plastic should have 'special priviledges' - we
+  5.2) No accounts on plastic should have 'special priviledges' - we
     need to assume that any account on plastic can be compromised
-  4.3) NO special passwords should be typed on plastic or the testbed
+  5.3) NO special passwords should be typed on plastic or the testbed
     nodes. This means don't telnet to the switches, ssh to any
     machines other than the testbed nodes, etc.