| | 1 | [[TOC]] |
| | 2 | |
| | 3 | '''Needs attention:''' |
| | 4 | * When Steve finds out how large the repo is, update the storage section |
| | 5 | * Someone investigate encrypted loopback images and expand that section |
| | 6 | * Policy issues needs more work |
| | 7 | |
| | 8 | == Running the malware == |
| | 9 | |
| | 10 | === Infrastructure security === |
| | 11 | |
| | 12 | Revisit the firewall rules on router to prevent leakage channels. Absolute minimum set of services should be allowed from testbed -> users/boss/etc. |
| | 13 | |
| | 14 | === Isolation from other experiments === |
| | 15 | |
| | 16 | Control net separation |
| | 17 | |
| | 18 | == Storage and Leakage == |
| | 19 | |
| | 20 | Primary goals are to allow vetted users to access the malware safely and prevent unauthorized users from gaining access. |
| | 21 | |
| | 22 | === Leakage of binaries === |
| | 23 | |
| | 24 | Some belt-and-suspenders support to prevent leakage is to export NFS shares read-only: |
| | 25 | |
| | 26 | * /proj, /groups, /share, etc. |
| | 27 | * home directories |
| | 28 | |
| | 29 | === Storage === |
| | 30 | |
| | 31 | Where/how we store it depends on how large it is. Steve is looking into this. |
| | 32 | |
| | 33 | * Loopback encrypted file system on users:/share, read only |
| | 34 | * Encryption options |
| | 35 | * Shared password |
| | 36 | * Revocation (is this necessary) |
| | 37 | * OS ID with strict access controls |
| | 38 | * Is it possible to limit the projects this is exported to? |
| | 39 | |
| | 40 | == Policy Issues == |
| | 41 | |
| | 42 | * Do not copy it off experiment |
| | 43 | * Do not attempt to run on non-malware experiment |
| | 44 | |
| | 45 | == Miscellaneous == |
| | 46 | |
| | 47 | Updates will probably be done via HTTPS with a client certificate. This depends on the GA guys. |
| | 48 | |
| | 49 | How will we annotate the experiment file to let the testbed know this needs special treatment (i.e., read-only mounts, copy encryption key/token to box)? |
