I have not looked at the BOINC code, but it would seem that the signatures should assure all of the following:
1) That no files have been inserted into the task 2) That no files have been removed from the task 3) That the command line is as issued by the project 4) That the files received are all consistent with the project If an application operates on all files downloaded, inserting a file into a task could change it's behavior. If an application names an executable on the command line, then clearly this must not be modified. If an application names an executable in a control file, there is the same concern. So, perhaps there should be an additional signature of all of the task's signatures to assure #1 and #2. But, to retain the existing flexibility, the signatures should NOT incorporate the download URLs nor path names. In other words, don't assume that the entire scheduler reply must travel without modification. The BOINC server may not be the only layer in the environment. Intermediate servers, so long as the files they serve match the project signatures, can presently be inserted into the scheduler reply without failing a signature check and I believe this is a desirable behavior. One example: a large corporate writes a superhost or BOINC proxy. All their client machines use it to provide the access to BOINC projects that are approved by the company. Firewalls assure this machine is the only one that can access a BOINC scheduler. To assure integrity of both incoming and outgoing data, they modify the scheduler reply. Stripping it of all references to project URLs and modifying it to hit their own local server for file downloads, saving bandwidth and affording extra integrity and virus checks on all the files. They also scan all outgoing data for any corporate information that would not be appropriate to leave the corporate network. (Anyone interested in doing such a thing should contact me. I've already got code that does most of the above.) You want to continue to allow this flexibility in any modification to handling of signatures. It affords ways of managing traffic. Yet, if you have all 4 criteria above, it should not introduce any additional exposure to hacks. Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running rose...@home just might! http://boinc.bakerlab.org/rosetta/ --- On Wed, 6/10/09, Mark Pottorff <[email protected]> wrote: > From: Mark Pottorff <[email protected]> > Subject: > To: "Me" <[email protected]> > Date: Wednesday, June 10, 2009, 6:51 AM > > Date: Tue, 09 Jun 2009 16:18:06 -0700 > From: David Anderson <[email protected]> > Subject: Re: [boinc_dev] Bug in update_versions? > To: Nicol?s Alvarez <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > You're right - I guess that code-signing is only relevant > to app files, since the client demands that they be > signed. > > Nicol?s Alvarez wrote: > > > > But what can a project admin do to enforce there has > to be a valid signature > > on a certain file? If a project sends its Python > scripts signed, what would > > stop a hacker from simply sending a workunit that > doesn't have a signature at > > all in the Python script? > > > > I think this is relevant to any project where the > input file format > > is "powerful enough" to cause harm if it's maliciously > created. > > > > > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
