Commit dae5b2b0 authored by Jay Lepreau's avatar Jay Lepreau
Browse files

Add caveat that some of this file might be superceded by other files'

contents.  Make understandable: s/paper/boss/ and s/plastic/ops/.
parent 62c1618d
This file contains notes about the security of the tesbed, and what should This file contains notes about the security of the tesbed, and what should
be done to enhance it: be done to enhance it. These notes are fairly old, so if there are
conflicts with more actively maintained files like setup*.*, believe
the latter.
1) Switches/Infrastucture hardware: 1) Switches/Infrastucture hardware:
1.1) Rules need to be set up on the control switch to restrict the 1.1) Rules need to be set up on the control switch to restrict the
IP/MAC that can be used on each port IP/MAC that can be used on each port
1.2) SNMP on the switches, power contollers, and anything else that 1.2) SNMP on the switches, power contollers, and anything else that
uses it should be restricted to paper's IP/switch port. uses it should be restricted to boss's IP/switch port.
2) Firewalling: 2) Firewalling:
2.1) Block outgoing connections from testbed nodes to the CS network 2.1) Block outgoing connections from testbed nodes to the CS network
- This is because something on this network may have (misguided) - This is because something on this network may have (misguided)
trust in them (especially paper/plastic) (note: This may be less trust in them (especially boss/ops) (note: This may be less
important when we're on our own subnets, as CS shouldn't be trusting important when we're on our own subnets, as CS shouldn't be trusting
them at all) them at all)
2.2) May want to block outgoing connections on specific ports to all 2.2) May want to block outgoing connections on specific ports to all
...@@ -22,15 +24,15 @@ be done to enhance it: ...@@ -22,15 +24,15 @@ be done to enhance it:
3.1) Home directories should be exported only to nodes currently 3.1) Home directories should be exported only to nodes currently
running experiments that the user is involved in (will be secure running experiments that the user is involved in (will be secure
because of item 1.1) because of item 1.1)
3.2) Home directories on Plastic should be mounted with the 'nosuid' 3.2) Home directories on ops should be mounted with the 'nosuid'
and 'nodev' options on plastic and paper - users could, on their and 'nodev' options on ops and boss - users could, on their
test nodes, create set-uid root programs, or make device nodes test nodes, create set-uid root programs, or make device nodes
that they are allowed to read an write to. The same is true for that they are allowed to read an write to. The same is true for
whatever filesystem you place /proj on; it should be mounted nosuid. whatever filesystem you place /proj on; it should be mounted nosuid.
3.3) Remove suidperl binary on plastic (doesn't get installed on 3.3) Remove suidperl binary on ops (doesn't get installed on
latest FreeBSD versions anyway) - See FreeBSD mount manpage for latest FreeBSD versions anyway) - See FreeBSD mount manpage for
reason. Related to item 3.2 reason. Related to item 3.2
3.4) All testbed nodes, and plastic (any maybe paper too?) should 3.4) All testbed nodes, and ops (any maybe boss too?) should
NOT be able to mount our NFS server(s) or CS's. Could happen NOT be able to mount our NFS server(s) or CS's. Could happen
either through firewalling or rules on the NFS servers. either through firewalling or rules on the NFS servers.
...@@ -38,28 +40,28 @@ be done to enhance it: ...@@ -38,28 +40,28 @@ be done to enhance it:
4.1) Testbed node root passwords are problematic. Testbed nodes 4.1) Testbed node root passwords are problematic. Testbed nodes
should definitely have a root password that is not used anywhere should definitely have a root password that is not used anywhere
else. Maybe they should have no root password (an invalid hash, 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. not a blank one) and just trust boss to login as root via ssh.
If someone who has local_root for a project crack a node's root 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 password, then they can get root on other project's nodes, or the
same node later, when another project owns it. Then again, maybe same node later, when another project owns it. Then again, maybe
we don't need to set our security stanards quite that high. 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 4.2) It would be reasonable to share a root password between boss
and the Cisco's. Having root on paper will mean that someone will and the Cisco's. Having root on boss will mean that someone will
have access through SNMP, etc. to the ciscos, and having the have access through SNMP, etc. to the ciscos, and having the
enable passwork to the ciscos will allow someone to bypass our enable passwork to the ciscos will allow someone to bypass our
protections in section 1 and spoof paper, so they are essentailly protections in section 1 and spoof boss, so they are essentailly
equivalent. equivalent.
4.3) Plastic should have a unique root password - we don't want to 4.3) ops should have a unique root password - we don't want to
have it the same as the testbed nodes (easy access to crack), but 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 we want to make root compromise of ops not lead to the root
compromise of paper. compromise of boss.
5) User policies: 5) User policies:
5.1) Flux'ers accounts on plastic and testbed nodes should not have 5.1) Flux'ers accounts on ops and testbed nodes should not have
stanard passwords (people may be able to get encrypted string and standard passwords (people may be able to get encrypted string and
crack) crack).
5.2) No accounts on plastic should have 'special priviledges' - we 5.2) No accounts on ops should have 'special privileges' - we
need to assume that any account on plastic can be compromised need to assume that any account on ops can be compromised
5.3) NO special passwords should be typed on plastic or the testbed 5.3) NO special passwords should be typed on ops or the testbed
nodes. This means don't telnet to the switches, ssh to any nodes. This means don't telnet to the switches, ssh to any
machines other than the testbed nodes, etc. machines other than the testbed nodes, etc.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment