On Tue, 16 Oct 2012, Arno Töll <a...@debian.org> wrote: > On 16.10.2012 14:00, Russell Coker wrote: > > There are a fairly small number of Debian servers. So even if the > > probability of system compromise for a Debian server was the same as for > > a laptop owned by a random DD the fact that DD workstations outnumber > > Debian servers by at least 200:1 makes them more of a risk. > > Not a strong argument. The impact of a compromise of a buildd [or J > Random Developer's machine running the buildd] is substantially higher > given the compromise would affect 30k source packages, as opposed to [1, > $whatever_gregoa_maintains_today[ of packages distributed amongst 950+ > individual machines.
An attacker wouldn't want to compromise all 30K packages, that would increase the risk of detection without increasing the benefit. They would want to compromise a very small number of relatively common packages. For example they could compromise Apache or a library it depends on, some library that is used by both KDE and GNOME, dash, bash, or a library used by shells. Compromising 100% of systems with a high probability of detection would be a lot less useful than compromising 50% with a low probability of detection. So compromising the workstation of a random DD who packages only some programs that aren't particularly popular wouldn't be a very effective attack in the short term. But using such an attack to target other DDs would be easier than using it to target build servers. For example an attacker who compromised a single program could file a bug report saying that it gave a SEGV when run with a new version of a particular library and have a good chance that the maintainer of the library would do a test... > Moreover, if you go down that path, you do not win anything of the state > being, as an attacker can still make a sourceful upload which enters the > archive unaudited as well. The advantage for the good people is that source can be audited. While it is difficult to audit source it's possible without huge effort, particularly as the changes made in the process of Debian packaging are generally small when compared to the upstream source. Currently we have no certainty of the version of the libraries and compiler used for building a package. So if a package has a different binary when it's rebuilt that isn't evidence of attack. Determining what parts of the binary change might be due to actual differences in operation of the program as opposed to the same logic with different compilation is going to take some work. Comparing two different versions of a Debian package at the source level to determine if the changes appear to match the changelog shouldn't be THAT difficult. Comparing two different binaries is going to be a lot harder. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210170023.43896.russ...@coker.com.au
