Request for Opinions: A secure way of sharing modules
Let's say that I'm regarded as smart enough to provide suggestions for this "something". And that I regard a number of people on daemonforums.org as considerably smarter then I am on such matters. For me, all of this is the best way of doing it that I can personally think of. If anyone is actually still interested after reading the basic idea below, I would really appreciate constructive comments on this thing, negative or positive alike -- because I'd rather be found wrong here then suggest it and see it put into use for this "something". And if anyone is wondering, no I do not really like creating threads like this.
Ok, this is the basic idea.
Users can install add in 'modules', hopefully downloaded from a trusted source.
Users can create 'modules' and have reputation based sharing, e.g. do good, project will host the module, do bad, your requests are > /dev/null.
The idea I was thinking about, for the process. The user would download the module and try to install it (software would of course take care of this). The module is an archive containing:
info file ------------------- details about module checksums file -------------- md/sha checksums of files archive files archive --------------- compressed archive containing files for this module
So in essence the installation process amounts to extracting the files archive into the right place, for them to be 'imported' locally.
We want to ensure that
The checksums file contains md5/sha256 checksums of the files archive, verifying those should reasonably prove that the archive is nether corrupt or tainted. To ensure that the checksums file has not been changed itself, such as by a malicious user wishing to drop a payload in a replacement files archive -- the checksums file is digitally signed with the private key of the modules author.
To verify the signature of the checksum file, we need the public key. So we download a digitally signed database file from a key server over HTTPS, which is *trusted* to have a valid database file. Once the database file is downloaded, we verify the database files signature with a public key specific to that key server.
The user does not need to trust the modules author or the files on the host, but they should be fairly sure that if the key server trusts the author, they won't get something malicious from the host site. This database file contains the necessary data to verify the digital signature on the checksum file -- comparing the fingerprint and author with listed in the info file, then on a match attempting to verify the checksum file with the corresponding public key in the database. In the advent of failure to verify, the user is essentially put in the "Proceed at your own risk, we warned you, so don't shout at us if you get burned!" boat. If the author of a module repeatedly submits crap, the public key is revoked and their keys removed from the trusted systems, then there modules are deleted from the host.
Does anyone see any big flaws in this, that I don't? Because the only biggest flaws I see is relying on fetching the database from the *right* host and getting the keys in the db cleanly. I'm not really a cryptography kind of guy but this is what idea I'm planning on recommending for this "something".
For the source of the modules:
A user wishing to share their custom modules with other users of the software service goes to a specified website. Creates an account with the necessary information and supplies a "salt" value for key generation. Combine parts of the account data and their salt value, apply a small series of modifications, that in the site designers theory should create a unique passphrase via one way hash function to use for the key pair, that can not be guessed solely on the input to the user account, and never (within reason) generate the same output from the same input or something like that I'm told.
Generate a DSA public/private key for the user account, saving the public key and giving the user their private key via HTTPS. This key pair might be created via third party software or through a suitable library.
The "key server" housing the database of author public keys, user names, and fingerprint, that this host trusts (in regard to the modules; not the actual user accounts of course!). Would have the keys entered into the database via some secure way of feeding them to the sever from the web host. <--- To me this is probably the weakest link. Another machine would then provide access to the server with the database via proxy. The outside accessible machine network mounts a read only copy of the database from the secure database server.
The theory being, if the server (e.g. proxy) that people will fetche a copy of the database from is compromised, there is no way for an attacker to corrupt the actual "master" copy of the database through the 'proxy server'. Unless they penetrate the network and gain a trusted shell on the actual box with the database. And to top it off, the database should be stored under a versioning system with the repository residing on yet another machine. The only machines directly exposed to account holders should be the proxy server for downloading the database and webservers providing account creation and the modules for download. The rest (e.g. real database server, repository for database, and probably authoritve storage for the modules) would be as segregated from the web servers as strongly they can make them.
Does this sound like a feasible implementation or is this whole phase of it just a brain fart?
Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
|Thread||Thread Starter||Forum||Replies||Last Post|
|Opinions about OS/2||indiocolifa||Off-Topic||8||14th December 2009 11:55 PM|
|kernel modules||Mr-Biscuit||FreeBSD General||0||2nd March 2009 06:18 AM|
|SXCE and Solaris: Opinions||ninjatux||Solaris||3||11th November 2008 11:41 PM|
|FTP users sharing same home directory||phreud||FreeBSD General||6||11th November 2008 10:11 PM|
|ILLEGAL REQUEST, PCI Error, SET_MULTI timeout - boot errors help||kTk||FreeBSD General||1||26th July 2008 03:34 AM|