mirror of https://github.com/BOINC/boinc.git
67 lines
2.4 KiB
HTML
67 lines
2.4 KiB
HTML
<h2>Security</h2>
|
|
|
|
<p>
|
|
There are two major areas of security in public-participation
|
|
computing projects: protection of the project,
|
|
and protection of the participants.
|
|
|
|
<p>
|
|
BOINC's support for redundant computing allows projects
|
|
to protect themselves from forged results and credit cheating.
|
|
For most other types of attacks,
|
|
the project is responsible for its own security.
|
|
All machines other then the scheduling server,
|
|
web servers, and data servers should be protected by a firewall.
|
|
The machines outside the firewall should have
|
|
all unused network services disabled.
|
|
Access to these machines should be done only
|
|
with encrypted protocols like SSH.
|
|
The machines should be subjected to regular security audits.
|
|
|
|
<p>
|
|
The input and output files used by BOINC applications
|
|
are not encrypted.
|
|
Applications can do this themselves, but it has little effect
|
|
since data resides in cleartext in memory,
|
|
where it is easy to access with a debugger.
|
|
|
|
<p>
|
|
The most important aspect of participant protection
|
|
is the distribution of executables.
|
|
If this is hacked, BOINC projects could be used
|
|
to spread viruses to all their participants.
|
|
<p>
|
|
The mechanism for distributing executables is as follows:
|
|
|
|
<ul>
|
|
<li> The participants host contacts the scheduling server.
|
|
<li> The scheduling server passes back the URL and
|
|
MD5 checksum of an executable
|
|
(it gets this information from the BOINC database).
|
|
<li> The client downloads the executable from the dataserver
|
|
and computes its checksum.
|
|
If this doesn't match the one obtained from the server,
|
|
the client rejects the executable.
|
|
</ul>
|
|
|
|
<p>
|
|
Compromising the data server is not a danger.
|
|
However, if the scheduling server or the database is compromised
|
|
then BOINC could be used to distribute viruses.
|
|
Furthermore, if hackers were able to intercept and alter
|
|
network traffic between client and server,
|
|
they could substitute false checksums and break the system.
|
|
|
|
<p>
|
|
<b>TO DO: allow for separate "authentication servers" that
|
|
are used only to distribute MD5 checksums of executables;
|
|
clients can cross-check these if they want.</b>
|
|
|
|
<p>
|
|
Participants must understand that when they join a BOINC project,
|
|
they are entrusting that project with the security of their systems.
|
|
The BOINC documentation must emphasize this,
|
|
and projects must devote sufficient resources to ensure their security.
|
|
A successful attack could discredit all BOINC-based projects,
|
|
and public-participation computing in general.
|