On Thu, 08 Dec 2011 04:34:57 +0900
夜神 岩男 <supergiantpotato(a)yahoo.co.jp> wrote:
An idea just struck me that may work.
If the system is made light enough that it is utterly painless for
anyone to contribute processing time then cross-checking of hashes
could be made statistically secure, save for a widespread compromise
of the entire Fedora userbase.
For example, if I just "yum install skyline"[1] and then set
"chkconfig skyline on" or whatever the systemd equivalent is (sorry,
haven't kept up lately) and my system just started pulling packages
to build/rebuild constantly in the background with a priority level
low enough I'd never notice it, then overnight Fedora as a project
would have FAR more build time than it needs.
So how is this secure?
Each time a build is made, the building system makes a hash of the
set of RPMs in $wherever/mock/result/{foo,bar} and sends the
completed data back to the Fedora build system.
Now the Fedora build system checks the hash to make sure it is
correct. Of course it is, because we've only got one sample.
But then we collect the other builds of the same RPM from, say, 10
other random systems and compare their hashes to what was received
from the initial build system.
A has that doesn't match whatever arises as the common hash is either
an error (likely considering the amount of transmission involved) or
poisoned. These will stick out like a sore thumb amongst the forest
of correct builds.
So how would I compromise this system? I would have to poison every
single SRPM departing the Fedora build infrastructure. Hard, maybe,
but possible.
How do we prevent that? Use SSL to transfer the packages in the first
place, and now that avenue is not available in the time allotted for
the attack to proceed.
This system depends chiefly on one thing: Having a boatload of
contributors. I think we could easily expect 1,000+ active
contributors, particularly if we make this a happy competition
complete with a stats tracker the way the BOINC and SETI@Home
trackers work. People who send more than 1 bad hash could be notified
by their system that things aren't working out which could be an
early warning in identifying whether the system is indeed being
attacked (or the individual's system has been compromised). A
throttle based on such indicators could let us know to halt the
distributed build and switch back to "old koji".
Just some ideas.
1. Sorry, silly package name idea from the image of city construction
"koji" + "cloud"
Bandwidth is the big concern for the end user here and then the other
issue is - is all of this worth it for building pkgs? I don't think it
is, personally, pkg building is not that huge of a hit, afaict to
getting things done.
I mean the sum total of the steps were talking about, even now is more
or less:
1. init host
2. stuff some files onto it
3. start up a process
4. communicate to that process
5. build pkg
6. stuff pkgs into a local repo
7. go to 5 until no more pkgs
8. download all pkgs back to original client
9. destroy host.
you can do it now if you're willing to do steps 5-8 manually.
-sv