Security-Policies.md

+Here is a brief rundown of some important security issues you should be
+aware of.
+
+### Login IDs
+
+We require all Emulab users to provide current, non-pseudonymic login
+IDs. **Shared accounts are strictly forbidden! Each user should apply
+separately and specify their standard login name**.
+
+### Cookies
+
+To enhance operation and security, we make use of _Cookies_ that holds
+your login name. Therefore, you will need to enable cookies on your
+browser. Please contact us if you have questions about how to do that in
+your browser.
+
+### SSL
+
+To protect data you submit, SSL is used to encrypt data as it is
+transferred across the Internet. Therefore, you will need to access these
+pages with a browser that supports SSL.
+
+When you first visit Emulab, you might be asked if you want to accept the
+_server certificate_. Be sure to accept it!
+
+### SSH
+
+We require all users to use Secure Shell (SSH) to log into Emulab
+nodes. Experience has taught us a few things about managing keys which we
+will pass on to you at no extra charge:
+
+  * You should **not** store your Emulab public key (.ssh/identity.pub) in
+    your authorized_keys file on remote sites. This prevents easy logins
+    from Emulab to your remote sites in case your Emulab account is ever
+    compromised (since the Emulab generated private key is not protected by
+    a passphrase). 
+  * You should **not** mess with the Emulab generated key in your .ssh
+    directory (.ssh/identity). This is an unencrypted key (see above) that
+    is used by Emulab when setting up experiments. You should not delete
+    the public part of the key from the web interface either. Failure to
+    heed this warning will result in experiments not setting up properly! 
+  * We recommend that you use ssh's RSA authentication to login to Emulab
+    so that you do not have to type your password. The less often you type
+    your password the better! You do this by uploading your own public keys
+    to Emulab. 
+  * When you create your private keys (ssh-keygen), pick a good passphrase!
+    They can be (much) longer than Unix passwords; 10 to 30 character
+    phrases are good. 
+  * You should **not** copy ssh identity files (private keys) from other
+    places to Emulab (or any other off-site machine, for that
+    matter). Private keys should always be well protected! 
+
+### Email Addresses
+
+We require all Emulab users to provide current, non-pseudonymic email
+addresses. Redirections and anonymous email addresses are not allowed. We
+do not sell or give your email addresses away!
+
+### Passwords
+
+We employ a password checking library to prevent users from choosing
+passwords that could be guessed by the "Crack" library. A few basic rules
+are that standard English dictionary words are not permitted, as well as
+anything deemed too short or easily guessable. Also, you should take care
+not to use the same password on Emulab that you use at other sites. 
+
+### Firewalling
+
+Emulab blocks incoming connections to nodes on all of the _low numbered_
+ports (ports below 1024), with the exception of ports 20 and 21 (FTP), 22
+(Secure Shell), and 80 (HTTP). This is for the protection of experimenters,
+as well help prevent an errant application from becoming the source of a
+Denial of Service attack to sites outside of Emulab. If your application
+requires external access to other low numbered ports, please contact us to
+make special arrangements.
+
+Emulab also prevents machines from using IP and MAC addresses other than
+their own on the control net. The control net router blocks all traffic not
+originating from the proper subnet, both to prevent IP spoofing and to
+prevent experimental traffic from accidentally making it to the 'real
+world' (say, through routing misconfiguration.) These restrictions are not
+present on the experimental net.
+
+### Ports used by Emulab
+
+If you wish to do firewalling of your own on your nodes, you should be
+aware that there are several ports used by Emulab that you'll need to keep
+open if you want your nodes to be able to function as "normal" Emulab
+nodes.
+
+In the table below, a direction of 'out' means that your node needs to be
+able to make outgoing TCP connections to a port, 'in' means that it needs
+to accept incoming connections on a port, and 'both' indicates UDP ports on
+which you must be able to send out packets and receive the replies.
+
+| Host | Port   | Protocol | Direction | Reason |
+| ---- | ------ | -------- | --------- | ------ |
+| boss | 22     | TCP      |  in       | ssh in from boss to reboot nodes |
+| boss | 53     | UDP      |  both     | DNS queries and replies |
+| boss | 123    | UDP      |  both     | NTP |
+| boss | 2917   | TCP      |  out      | pubsub event system |
+| boss | 7777   | TCP/UDP  |  both     | Testbed Master Control Daemon |
+| ops  | 1024   | UDP      |  both     | Portmapper for NFS, etc. |
+| ops  | 2049   | UDP      |  both     | NFS |
+
+### Accounts
+
+We make use of Unix user and group mechanisms to provide protection between
+users and projects. Each new user gets a new Unix UID, and each new project
+gets a new Unix GID. Users are members of the Unix groups that correspond
+to each of the projects they are working on, and thus may share files with
+other members of those projects. The default directory permissions are set
+so that project files are not readable by members of other projects.
+
+Each project gets its own directory hierarchy (again, protected by the Unix
+group mechanism) that is NFS-exported only to that project's assigned test
+machines. We don't currently protect against spoofing on the control
+network, so there are vulnerabilities. The test networks are fully
+separated between experiments by way of VLANs.