Security Considerations with SAMI
The Secure and Accountable Measurement Infrastructure (SAMI) is a collection of software tools designed to aid researchers and engineers in managing internet measurements from various vantage points within the internet. This document discusses the security issues involved in using SAMI. See the SAMI Overview document for general SAMI information.
Please note that in this document, INSTALL_DIRECTORY represents the SAMI root directory.
The security algorithms used within SSL are only as good as the pseudo-random number generator on the system. OpenSSL 0.9.7 and greater will balk if the the random number generation isn’t sufficient.
OpenSSL provides many ciphers, and some are known to be vulnerable to attacks. Running any SAMI component in “verbose mode” (-v option) will report which ciphers are chosen during any SSL negotiation. It is up to the system administrator of the SAMI components to limit the ciphers accordingly.
The required libraries can, under certain circumstances (e.g., requiring a schema or a certficate), initiate a network connection. At this time, we are not certain as to the best mechanism to limit or prevent this.
Currently, SAMI does not support Certficate Revocation Lists (CRL). The TeraGrid Certificate Authority that was used to initally implement SAMI uses kX.509 certificates generated by a Kerberos Certificate Authority, and hence, these certificates do not have a CRL associated with them.
As the samid will be started without human intervention, the RSA private key, used by the X.509 certificate for the box, will not be passphrase protected. Thus, it is imperative that the file is readable only by user sami in a directory readable only by user sami.
After the samid authorizes a particular request, it places that request in the~sami/measurements/pending directory. Again, this directory should be readable and accessible only by user sami. Else, anyone with local access would be able to drop their request into that directory and bypass all of SAMI’s authorization and authentication, as the scheduled performs no authorization checks.
The scheduled actually calls just one script, master-script; therefore, it is imperative that the master-script remain immutable.
Moreover, the master-script calls the tool invocation scripts via an absolute path. However, the invocation scripts themselves are not directly under our control, and out of convenience, usually call the tool under the assumption that a sufficient PATH environment variable has been set by the master-script. Ideally, the invocation scripts are vetted by the administrator of the CPOC prior to being downloaded to the SAMI probe. But if the SAMI probe is considered hostile (e.g., other users are using the box), then it is conceivable (even if highly unlikely) that a malicious tool with the same name could be placed earlier in the path. Therefore, the master-script can be built by defining PATH_UNTRUSTED, which will explicitly set $PATH to TOOL_PATH, which is:
as opposed to having the above path appended to the existing $PATH. Likewise, TOOL_PATH can be refined to limit the location of available tools.
The root policy certificate (~sami/akenti/tools/htauthority) that Akenti uses is a self-signed certificate; hence, it must only be readable by the CPOC user.