REDDnet LStore Security Overview
REDDNet's current security plan maintains a level of security that balances security requirements with the service and academic freedom our users expect. We are capable of enforcing stricter security measures than those outlined in this document should a specific need arise.
|Primary||Mathew Binkley||Phone: (615) 322-5857|
|Secondary||Alan Tackett||Phone: (615) 322-1028|
L-Store is currently under development. At the moment, data is not encrypted in transit or in storage. If the user desires, they may use common encryption tools such as OpenSSL or GnuPG to encrypt their data before uploading.
Cursory work on an OpenSSL-encrypted upload/download has been done, but is not yet ready for public use.
When the client uploads a file to the depots, it can optionally compute a MD5 hash of the file and store that information in the metadata on the server. Downloaded files can be hashed and compared with the stored value to verify integrity (though this is not yet automated).
We intended to make the choice of hash user-selectable in the future. We intend to support SHA-1, SHA-256, SHA-512 hashes, and possibly other hashes as supported by the base SSL library.
Data stored on depots is encoded with RAID 5 redundancy. The user may specify this redundancy across hard drives, across depots, and/or across sites. REDDNet monitors depots for drive failures using Nagios, and if a loss of redundancy is detected we correct the error on our end.
In addition, we are working on a generalized Reed-Solomon code that will allow users to specify an arbitrary amount of redundancy. For example, you could have 10 drives and have 4 of them fail before you lost redundancy. We expect this generalized redundancy code to be completed in summer 2010.
We are implementing a generic policy framework that allows for custom security policies (role-based, Unix ACL and permissions) based on user requirements.