Re: Building packages with exact binary matches
On Fri, Sep 28, 2007 at 09:18:12PM -0500, Manoj Srivastava wrote: On Fri, 28 Sep 2007 23:04:00 +0200, Martin Uecker [EMAIL PROTECTED] said: There is some other thing I do not like about the way Debian packages work. Every package I install can actually completely compromise my system, because the maintainer scripts are run as root. You can, of course, run a strict mode SELinux system, and see that the apt_t security domain is sufficiently confined for your tastes (you may have a local security policy that tightens down the default project wide constraints, to the level you heart desires). That would be an option. But it is exactly like the problem with windows applications: Since the applications are used to having the privileges, it is much harder to lock them down. Martin
Re: Building packages with exact binary matches
On Thu, Sep 27, 2007 at 06:31:58PM -0500, Manoj Srivastava wrote: On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker [EMAIL PROTECTED] said: [...] But recompiling from what? If you do not get the exact same source, you have no hope of getting the same result. I had the impression that Debian distributes the source code from which the binaries are actually compiled and not some random variation. Yup, complete with all the trojans in the binary and all. You are seriously stating that is as easy to hide a trojan in the source code as in the binary? I have seen a lot trojans hiding in binaries but I have never seen that an open source project distributed trojaned source code. Maybe they where such incidents but there are certainly rare. And the way things work, the chances are that if the binary is tainted, the source would be tainted -- and you have got nowhere. If I wanted to hide a trojan somewhere I would to it in the binary and not in the source code. People actually look into source code on a regular basis but they seldom disassemble a binary. The window of opportunity is small. You have to replace the binary .deb in between the time it was built, and it was signed. That's a small window if you measure the time but it is not small window of opportunity. If the building host is compromised than it is trivial. And it seems that DDs do upload binaries which are compiled on their local machines. So it is actually enough if any of those machines is compromised. [..] So, someone replaces the binary compiled on the buildd with a fake one, in between the binary being built and it being signed? All the work to get bit-for-bit reproducibility for such a low priority attack vector? I do not think it is a low priority attack vector. If I would be a cracker and had a rootkit installed on a debian build host it would certainly insert a backdoor in ssh everytime it is compiled: Access to all debian running computers world wide! Compromise gcc? I see. So, fro all you know, every copy of gcc in the world now has the compile trojan into ssh built in, and again, no way for people peering at bits to see if there is a trojan buried in there to find out. Why all copies of gcc? A single copy of a gcc on a single host where official debian packages are compiled. And the gcc binary on the disc is unmodified: The compiler is patched after loading it in the memory by a rootkit. Not that a single binary copy of gcc was ever completely dissassembled and checked for trojans. That would probably take at least a year to do. BTW I did some tests and for 'dpkg' the only files which change between builds are the manpages and that's just because gzip stores the date of the orginal in the compressed file. This is one of the things, yes. ANy package with a tar archive would suffer similarly. That all files which are created by the actualy build process are already bit-identical (for dpkg) and only a postprocessing step adds time stamps is very promising, I think. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Fri, 28 Sep 2007, Martin Uecker wrote: You are seriously stating that is as easy to hide a trojan in the source code as in the binary? Consider the fact that we've already had such a case,[1] whereas we've not (to my knowledge) distributed a trojaned binary. I'm not sure which is easier to hide, but it seems that making a source trojan is at least more frequent if not easier to create. Don Armstrong 1: mICQ anyone? http://lists.debian.org/debian-devel/2003/02/msg00872.html -- [A] theory is falsifiable [(and therefore scientific) only] if the class of its potential falsifiers is not empty. -- Sir Karl Popper _The Logic of Scientific Discovery_ §21 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Building packages with exact binary matches
On Fri, Sep 28, 2007 at 09:05:59AM -0700, Don Armstrong wrote: On Fri, 28 Sep 2007, Martin Uecker wrote: You are seriously stating that is as easy to hide a trojan in the source code as in the binary? Consider the fact that we've already had such a case,[1] whereas we've not (to my knowledge) distributed a trojaned binary. I'm not sure which is easier to hide, but it seems that making a source trojan is at least more frequent if not easier to create. I would not call this a trojan. But I guess I have to change my opinion anyway. Manoj is right: Trojaned upstream sources are a major security risk, against which exact binary matches do not help. But I still think they would still eliminate a lot of other risks, which should IMHO not be ignored. There is some other thing I do not like about the way Debian packages work. Every package I install can actually completely compromise my system, because the maintainer scripts are run as root. It would be nice if normal packages would not be allowed to have maintainer scripts and would only be allowed to install binaries in certain paths. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Fri, Sep 28, 2007 at 11:04:00PM +0200, Martin Uecker wrote: There is some other thing I do not like about the way Debian packages work. Every package I install can actually completely compromise my system, because the maintainer scripts are run as root. It would be nice if normal packages would not be allowed to have maintainer scripts and would only be allowed to install binaries in certain paths. Please define a normal package. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Building packages with exact binary matches
On Fri, 28 Sep 2007 23:04:00 +0200, Martin Uecker [EMAIL PROTECTED] said: There is some other thing I do not like about the way Debian packages work. Every package I install can actually completely compromise my system, because the maintainer scripts are run as root. You can, of course, run a strict mode SELinux system, and see that the apt_t security domain is sufficiently confined for your tastes (you may have a local security policy that tightens down the default project wide constraints, to the level you heart desires). manoj -- ...and it's finished! It only has to be written. Karl Lehenbauer Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker [EMAIL PROTECTED] said: On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote: Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. It is not about hearsay. It is about finding an error in a predictation. And I do not care *who* finds the error. Of course the predications have actually be checked. So you are right with your argument, if nobody actually does this, it would be ignorant to believe in a scientifc theory for the sole reason that nobody complains. Similar, if nobody recompiles the packages and checks for mismatches, then silence would in fact not imply that things are ok. But I question your premise: I have no doubt that some people would actually recompile packages and compare the hash. Even if it is not done normally, somebody would do this if doubts come up for some reason (e.g. some debian hosts are compromised again.). This alone would actually be worth a lot. But recompiling from what? If you do not get the exact same source, you have no hope of getting the same result. And the way things work, the chances are that if the binary is tainted, the source would be tainted -- and you have got nowhere. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. If know that the source code wich has hash 4457575757575 compiled in the build environment with hash 4837373737 gives a package with hash 366336363, then it is actually *evidence* that something is seriously wrong if you end up with a package with a different hash. So, someone replaces the binary compiled on the buildd with a fake one, in between the binary being built and it being signed? All the work to get bit-for-bit reproducibility for such a low priority attack vector? manoj -- VMS is a text-only adventure game. If you win you can use Unix. Bill Davidsen ([EMAIL PROTECTED]) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
Ben Finney [EMAIL PROTECTED] wrote: Martin Uecker [EMAIL PROTECTED] writes: On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Really? I trust the theory of special relativity because there is enormous evidence supporting it, and little evidence against it. There is enormous evidence for the Aristotle' believe that more massive objects fall faster and little evidence against it. Only a carefully crafted experiment shows that it is false. In the case of there are no messages, therefore I trust the security of the system, that's faith â belief in spite of an utter lack of evidence. The predictions must be testable by everbody and - of course - some must actually try to falsify them. Exact binary matches would allow everbody to check the integrity of the binary packages and I am quite sure that some people would do it. In this case no messages stating that something is wrong is not the same as lack of evidence, it is actually evidence for the assumption that everything is ok. Do you think this is blissfull ignorance, too? Worse, it's foolish. It is foolish to base his trust purely on the authority of some person. People's belief that massive objects fall faster was based on the authority of Aristotle. Debian user's trust in the integrity of some binary package is based on the authority of the person putting a gpg signature on it. In the lack of *any* evidence either way on a question, it's foolish to hold any position but unknown; That is a common misbelief. Some things are inherently more probable than other. and, if the question is important for a matter of trust, it's imperative to *get* some evidence before extending any trust. That is certainly true. Martin
Re: Building packages with exact binary matches
On Thu, Sep 27, 2007 at 02:26:49AM -0500, Manoj Srivastava wrote: On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker [EMAIL PROTECTED] said: On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote: Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. It is not about hearsay. It is about finding an error in a predictation. And I do not care *who* finds the error. Of course the predications have actually be checked. So you are right with your argument, if nobody actually does this, it would be ignorant to believe in a scientifc theory for the sole reason that nobody complains. Similar, if nobody recompiles the packages and checks for mismatches, then silence would in fact not imply that things are ok. But I question your premise: I have no doubt that some people would actually recompile packages and compare the hash. Even if it is not done normally, somebody would do this if doubts come up for some reason (e.g. some debian hosts are compromised again.). This alone would actually be worth a lot. But recompiling from what? If you do not get the exact same source, you have no hope of getting the same result. I had the impression that Debian distributes the source code from which the binaries are actually compiled and not some random variation. And the way things work, the chances are that if the binary is tainted, the source would be tainted -- and you have got nowhere. If I wanted to hide a trojan somewhere I would to it in the binary and not in the source code. People actually look into source code on a regular basis but they seldom disassemble a binary. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. If know that the source code wich has hash 4457575757575 compiled in the build environment with hash 4837373737 gives a package with hash 366336363, then it is actually *evidence* that something is seriously wrong if you end up with a package with a different hash. So, someone replaces the binary compiled on the buildd with a fake one, in between the binary being built and it being signed? All the work to get bit-for-bit reproducibility for such a low priority attack vector? I do not think it is a low priority attack vector. If I would be a cracker and had a rootkit installed on a debian build host it would certainly insert a backdoor in ssh everytime it is compiled: Access to all debian running computers world wide! BTW I did some tests and for 'dpkg' the only files which change between builds are the manpages and that's just because gzip stores the date of the orginal in the compressed file. Martin
Re: Building packages with exact binary matches
On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker [EMAIL PROTECTED] said: On Thu, Sep 27, 2007 at 02:26:49AM -0500, Manoj Srivastava wrote: On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker [EMAIL PROTECTED] said: On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote: Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. It is not about hearsay. It is about finding an error in a predictation. And I do not care *who* finds the error. Of course the predications have actually be checked. So you are right with your argument, if nobody actually does this, it would be ignorant to believe in a scientifc theory for the sole reason that nobody complains. Similar, if nobody recompiles the packages and checks for mismatches, then silence would in fact not imply that things are ok. But I question your premise: I have no doubt that some people would actually recompile packages and compare the hash. Even if it is not done normally, somebody would do this if doubts come up for some reason (e.g. some debian hosts are compromised again.). This alone would actually be worth a lot. But recompiling from what? If you do not get the exact same source, you have no hope of getting the same result. I had the impression that Debian distributes the source code from which the binaries are actually compiled and not some random variation. Yup, complete with all the trojans in the binary and all. And the way things work, the chances are that if the binary is tainted, the source would be tainted -- and you have got nowhere. If I wanted to hide a trojan somewhere I would to it in the binary and not in the source code. People actually look into source code on a regular basis but they seldom disassemble a binary. The window of opportunity is small. You have to replace the binary .deb in between the time it was built, and it was signed. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. If know that the source code wich has hash 4457575757575 compiled in the build environment with hash 4837373737 gives a package with hash 366336363, then it is actually *evidence* that something is seriously wrong if you end up with a package with a different hash. So, someone replaces the binary compiled on the buildd with a fake one, in between the binary being built and it being signed? All the work to get bit-for-bit reproducibility for such a low priority attack vector? I do not think it is a low priority attack vector. If I would be a cracker and had a rootkit installed on a debian build host it would certainly insert a backdoor in ssh everytime it is compiled: Access to all debian running computers world wide! Compromise gcc? I see. So, fro all you know, every copy of gcc in the world now has the compile trojan into ssh built in, and again, no way for people peering at bits to see if there is a trojan buried in there to find out. BTW I did some tests and for 'dpkg' the only files which change between builds are the manpages and that's just because gzip stores the date of the orginal in the compressed file. This is one of the things, yes. ANy package with a tar archive would suffer similarly. manoj -- The bug starts here. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote: On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker [EMAIL PROTECTED] said: [...] No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? Actually, partly. I am a quantum mechanic by training (I just went sideways into computer because there was so little money in devoce modeling). I like the special relativity because the math is sound; it has predicted things we were not aware of before; and all kinds of experimental data matches the theory -- except when you get to very very small dimensions, but people are still working on that. I am a mathematical phycicist by training: There are no known problems with the SRT at the small scale. But you are right with your other point: The math of a scientific theory has to be sound. But it has to be related to reality, too. It is the last part we are talking about. Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. It is not about hearsay. It is about finding an error in a predictation. And I do not care *who* finds the error. Of course the predications have actually be checked. So you are right with your argument, if nobody actually does this, it would be ignorant to believe in a scientifc theory for the sole reason that nobody complains. Similar, if nobody recompiles the packages and checks for mismatches, then silence would in fact not imply that things are ok. But I question your premise: I have no doubt that some people would actually recompile packages and compare the hash. Even if it is not done normally, somebody would do this if doubts come up for some reason (e.g. some debian hosts are compromised again.). This alone would actually be worth a lot. [...] So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Really? What was the last time anyone looked through libsepol library code, eh? Or libselinux code? You do know dpkg and coreutils are linked to that? I would assume that there are people hacking on this code or at least somebody fixes a bug in it occasionally. I know I looked at the source code of libselinux once (but not closely). If in fact some code is never looked at, then it is propably a really bad idea to include it in critical packages. All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? No, the bug reporter goes and presents _evidence_ that can be checked, and a patch, or a source of the problem. No one jumps up and down and issue CVE's just become someone says things are not ok. And no one makes a security ssue go away if bunches of people rise up and say the code is juuust fiiine. I never claimed that I believe random people just saying things are ok or not ok. A binary mismatch is *evidence*. So if some random people come up with such evidence, then I can check it myself. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. If know that the source code wich has hash 4457575757575 compiled in the build environment with hash 4837373737 gives a package with hash 366336363, then it is actually *evidence* that something is seriously wrong if you end up with a package with a different hash. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. If you do not know who the signatories of the archive key are, I suggest you leanr, and see how the web of trust thing works for you, and whether or not you can trust the guy doing the builds. Nothing is bullet proof. And no one can make anyone trust anyone, including themselves. Like all security ractices, it is a tradeoff. I have decided to trust my fellow DD's, and to trust the
Re: Building packages with exact binary matches
On Mon, Sep 24, 2007 at 06:16:57PM -0700, Russ Allbery wrote: Right now, it's also badly out of date in several respects and not in a position to lead any charge. Manoj and I have both been eaten by our respective day jobs, there are a ton of obvious fixes that should go into the next release, and the work is, er, not being spread at all beyond the two of us. There are 5 Policy delegates listed at http://www.debian.org/intro/organization . There are 5 users who appear to have commit access. These sets are not even close to identical. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. Martin
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 01:03:27AM +0100, Benjamin A'Lee wrote: On Tue, Sep 25, 2007 at 12:04:15AM +0200, Martin Uecker wrote: Manoj Srivastava [EMAIL PROTECTED] wrote: Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Erm, if I can't trust the Debian Project to create trustworthy packages and verify their integrity, why should I trust anyone else to verify them? No, I trust that somebody would *falsify* them if there are compromised. See my reply to Manoj for an explanation. [...] You're also assuming that the source code is trustworthy. If the binary packages can be compromised, so can the source packages. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Martin
Re: Building packages with exact binary matches
Clint Adams [EMAIL PROTECTED] writes: On Mon, Sep 24, 2007 at 06:16:57PM -0700, Russ Allbery wrote: Right now, it's also badly out of date in several respects and not in a position to lead any charge. Manoj and I have both been eaten by our respective day jobs, there are a ton of obvious fixes that should go into the next release, and the work is, er, not being spread at all beyond the two of us. There are 5 Policy delegates listed at http://www.debian.org/intro/organization . There are 5 users who appear to have commit access. These sets are not even close to identical. Yeah. I, or Manoj, or somebody needs to ping the union of those two sets and try to figure out who's interested. If people want to work on Policy and are just blocked because they don't know how to technically go about it, I would be quite happy to answer questions, and I'm sure Manoj would as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Everyone does that now based on debian archive signatures. You do not need bit-by-bit verification for that. So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Ah. again, assume security until someone pulls us out of our ignorance. So easy to do a denial of service attack by random slander of binaries and source (thanks, helpful botnet). Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. I kinda find your alternate shceme, based on bit-for-bit sameness, not to be all that secure, really. It is a feel good thing with little added secueity. However, this is all moot; unless someone does all the work to make things absolutely bit-for-bit the same, compile after compile, and manages to convince all the package ownsers to accept the changes, this is going nowhere. I am not even sure it can be done, technically. manoj -- Work without a vision is slavery, Vision without work is a pipe dream, But vision with work is the hope of the world. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Everyone does that now based on debian archive signatures. You do not need bit-by-bit verification for that. Again: How does this protect against a compromised build host? So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Its exactly the same: Because the source code is open, I would hope that somebody would find the backdoor. Ah. again, assume security until someone pulls us out of our ignorance. See above. So easy to do a denial of service attack by random slander of binaries and source (thanks, helpful botnet). All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? Compare this to the current system: The trustworthiness of *all* DDs wich maintain packages which are installed on my systems, the security of *all* computers those DDs store their keys on, the security of the build host, the gpg signatures and the md5sums are actually a chain of trust where the weakest link determines the total security. I kinda find your alternate shceme, based on bit-for-bit sameness, not to be all that secure, really. It is a feel good thing with little added secueity. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. However, this is all moot; unless someone does all the work to make things absolutely bit-for-bit the same, compile after compile, and manages to convince all the package ownsers to accept the changes, this is going nowhere. I am not even sure it can be done, technically. You are right: Currently, this is all moot. But I find this discussion very interesting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
Martin Uecker [EMAIL PROTECTED] writes: On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Really? I trust the theory of special relativity because there is enormous evidence supporting it, and little evidence against it. In the case of there are no messages, therefore I trust the security of the system, that's faith — belief in spite of an utter lack of evidence. Do you think this is blissfull ignorance, too? Worse, it's foolish. In the lack of *any* evidence either way on a question, it's foolish to hold any position but unknown; and, if the question is important for a matter of trust, it's imperative to *get* some evidence before extending any trust. -- \ A society that will trade a little liberty for a little order | `\ will lose both, and deserve neither. —Thomas Jefferson, in a | _o__)letter to Madison | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker [EMAIL PROTECTED] said: On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? Actually, partly. I am a quantum mechanic by training (I just went sideways into computer because there was so little money in devoce modeling). I like the special relativity because the math is sound; it has predicted things we were not aware of before; and all kinds of experimental data matches the theory -- except when you get to very very small dimensions, but people are still working on that. Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. people that things are *not ok*. Because everybody can check that the binaries are not compromised, you can actually be quite sure that things are ok, as long as nobody complains. And if doubts come up, I can check myself. This actually the same principle on wich science is build: falsifiability. Everyone does that now based on debian archive signatures. You do not need bit-by-bit verification for that. Again: How does this protect against a compromised build host? Doesn't. So, if the archive signature has not been compromised, this is a probably a buggy source. Rebuilding from the tainted source gets you nowhere. But the common case is not this is. Compromised buildd's are a rare occurrence; and when it is detected, auditing the sources and rebuilding on a clean machine is a far better solution than bit for bit same binaries (which is not really much better than the signed Packages file unless you have a trusted path to the sources, which you do not. This lack of a trusted path does the whole let's all rebuild from source and compare our binaries bit. So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Really? What was the last time anyone looked through libsepol library code, eh? Or libselinux code? You do know dpkg and coreutils are linked to that? All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? No, the bug reporter goes and presents _evidence_ that can be checked, and a patch, or a source of the problem. No one jumps up and down and issue CVE's just become someone says things are not ok. And no one makes a security ssue go away if bunches of people rise up and say the code is juuust fiiine. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. If you do not know who the signatories of the archive key are, I suggest you leanr, and see how the web of trust thing works for you, and whether or not you can trust the guy doing the builds. Nothing is bullet proof. And no one can make anyone trust anyone, including themselves. Like all security ractices, it is a tradeoff. I have decided to trust my
Re: Building packages with exact binary matches
On Mon, Sep 24, 2007 at 03:34:35PM +1000, Ben Finney wrote: You seem to be suggesting that policy should require this *before* it becomes common practice. That's not generally how policy is crafted: Debian policy generally does not prescribe packaging practice, but rather describes it. Calling it policy is misleading then. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Mon, 24 Sep 2007 03:30:48 -0400, Clint Adams [EMAIL PROTECTED] said: On Mon, Sep 24, 2007 at 03:34:35PM +1000, Ben Finney wrote: You seem to be suggesting that policy should require this *before* it becomes common practice. That's not generally how policy is crafted: Debian policy generally does not prescribe packaging practice, but rather describes it. Calling it policy is misleading then. I don't think that follows. It is not as if packages do not have to follow policy once it is written -- either it is a bug in the package, or it is a bug in the policy. What we are talking about is how changes get into policy. In a project that is loosely coupled, geographically distributed, and has an extremely flat org chart, policy changes necessarily have to be conservative; and our preference is changing Debian by persuasion and near consensus, not by edicts from above (since there is so very little above). This is not to say that policy will _never_ lead the change -- but that is a very exceptional case, and probably would need to be ratified by, say, the tech ctte. manoj -- I got everybody to pay up front...then I blew up their planet. Now why didn't I think of that?-- Post Bros. Comics Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
Manoj Srivastava [EMAIL PROTECTED] wrote: On Mon, 24 Sep 2007 04:56:45 +0200, Martin Uecker [EMAIL PROTECTED] said: If policy would require the exact reproducability of binaries, then it would be a policy violation. That is not how things work around here. In a case like this, policy will _follow_ most packages being bit-for-bit identical, and can't be used as a stick to beat people on the head with. Ok. I do not see how this helps. Imagine a build host is compromised and this is noticed only after a few weeks. Theoretically every machine which downloaded and installed a package in this time could be compromised. And even worse: it is practically impossible to find out wether a package is actually affected! Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] wrote: On Mon, 24 Sep 2007 04:56:45 +0200, Martin Uecker [EMAIL PROTECTED] said: Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Err, what? Why would everyone do that? I mean, you do not trust the Debian distribution system, the archive gpg signatures, the md5sums on the package, etc, and ye5t you are willing to accept mails from other people that things are oK? Given a sufficiently large BOTNET, I cal send am million or so emails, joe jobs and all, saying that the original source is juust fine, folks. You believe that, I have a bridge over in manhattan ... manoj -- Everybody needs a little love sometime; stop hacking and fall in love! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Tue, Sep 25, 2007 at 12:04:15AM +0200, Martin Uecker wrote: Manoj Srivastava [EMAIL PROTECTED] wrote: Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. It would be enough when just a few people are actually recompiling the binaries and compare it to the official debian packages. Then *everbody* could trust that the packages are not modified, because any modification would be detected immediatley. This is only possible with bit-identical binaries. Erm, if I can't trust the Debian Project to create trustworthy packages and verify their integrity, why should I trust anyone else to verify them? And why should anyone trust anyone else? A security system like this would only make sense if everyone did it, and if you're going to recompile every single package to make sure it's trustworthy, then you may as well be using FreeBSD, Gentoo, or similar... You're also assuming that the source code is trustworthy. If the binary packages can be compromised, so can the source packages. -- Benjamin A'Lee [EMAIL PROTECTED] http://subvert.org.uk/~bma/ signature.asc Description: Digital signature
Re: Building packages with exact binary matches
Clint Adams [EMAIL PROTECTED] writes: On Mon, Sep 24, 2007 at 03:34:35PM +1000, Ben Finney wrote: You seem to be suggesting that policy should require this *before* it becomes common practice. That's not generally how policy is crafted: Debian policy generally does not prescribe packaging practice, but rather describes it. Calling it policy is misleading then. Right now, it's also badly out of date in several respects and not in a position to lead any charge. Manoj and I have both been eaten by our respective day jobs, there are a ton of obvious fixes that should go into the next release, and the work is, er, not being spread at all beyond the two of us. All of which are serious problems that need to be remedied, but until they are, my enthusiasm for leading any major charge through policy is pretty low, even apart from the fact that practically speaking it won't happen because there hasn't been a Policy upload in nearly a year. I have just enough time to feel guilty and not enough time at the moment to do anything concrete about it, which is a wonderful situation. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
On Mon, 24 Sep 2007 00:54:58 +0200 Martin Uecker [EMAIL PROTECTED] wrote: Neil Williams [EMAIL PROTECTED]: Martin Uecker [EMAIL PROTECTED] wrote: This has been covered before - certain upstream macros are among many factors that ensure that this is unlikely. I, for one, use such macros upstream to indicate the build time of the actual executable installed so this will change the binary every time it is built. This could be fixed. Fixed?? What the? You're asserting that this is a PROBLEM to be fixed? It's good, it's useful, it's helpful. I'm confused, what is wrong with that? :-( IMNSHO, this is not a bug, there is no good reason to prevent upstream from using such macros and besides, there are other upstream processes that modify the built binaries every time the build proceeds. Think Latex and various other generation tools. Also, any build process generates files that contain different references and linked objects - if a package hasn't been built for a while (no new uploads), what on earth is wrong with that not being a binary-match for a package that was built yesterday against updated libraries? See also this thread: http://lists.debian.org/debian-devel/2007/07/msg00588.html and http://lists.debian.org/debian-devel/2007/06/msg01076.html If the dependencies change between builds, so will the binary. You have md5sums and GnuPG signatures on the Release files - I see no benefit from bit-matching. The build host could be compromised. Not that unlikely. That's why the autobuild process is not entirely automated. A real DD needs to sign off the ported packages. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpPV8JohKh4z.pgp Description: PGP signature
Re: Building packages with exact binary matches
On Mon, 24 Sep 2007 00:54:58 +0200 Martin Uecker [EMAIL PROTECTED] wrote: Neil Williams [EMAIL PROTECTED]: This has been covered before - certain upstream macros are among many factors that ensure that this is unlikely. I, for one, use such macros upstream to indicate the build time of the actual executable installed so this will change the binary every time it is built. ac This could be fixed. Fixed?? What the? You're asserting that this is a PROBLEM to be fixed? If policy would require the exact reproducability of binaries, then it would be a policy violation. It's good, it's useful, it's helpful. I'm confused, what is wrong with that? :-( I do not see how a date stamp in a binary is really usefull. Often it is just used as a cheap replacement of fine grained versioning information. But I do not think that's a good reason. The date on which a binary is built is actually completely irrelevant from a technical point of view. What's really usefull is the exact version of the source code and the build tools. Everything else should not matter at all! IMNSHO, this is not a bug, there is no good reason to prevent upstream from using such macros Ofcourse there is: reproducability and besides, there are other upstream processes that modify the built binaries every time the build proceeds. Think Latex and various other generation tools. These could be fixed too ;-) Also, any build process generates files that contain different references and linked objects - if a package hasn't been built for a while (no new uploads), what on earth is wrong with that not being a binary-match for a package that was built yesterday against updated libraries? See also this thread: http://lists.debian.org/debian-devel/2007/07/msg00588.html and http://lists.debian.org/debian-devel/2007/06/msg01076.html If the dependencies change between builds, so will the binary. That's an different issue. I am not complaing about the fact that binaries can change without source code changes, but that it is impossible to create an identical package even when you try. You have md5sums and GnuPG signatures on the Release files - I see no benefit from bit-matching. The build host could be compromised. Not that unlikely. That's why the autobuild process is not entirely automated. A real DD needs to sign off the ported packages. I do not see how this helps. Imagine a build host is compromised and this is noticed only after a few weeks. Theoretically every machine which downloaded and installed a package in this time could be compromised. And even worse: it is practically impossible to find out wether a package is actually affected! Martin
Re: Building packages with exact binary matches
On Mon, 24 Sep 2007 04:56:45 +0200, Martin Uecker [EMAIL PROTECTED] said: On Mon, 24 Sep 2007 00:54:58 +0200 Martin Uecker [EMAIL PROTECTED] wrote: Neil Williams [EMAIL PROTECTED]: This has been covered before - certain upstream macros are among many factors that ensure that this is unlikely. I, for one, use such macros upstream to indicate the build time of the actual executable installed so this will change the binary every time it is built. ac This could be fixed. Fixed?? What the? You're asserting that this is a PROBLEM to be fixed? If policy would require the exact reproducability of binaries, then it would be a policy violation. That is not how things work around here. In a case like this, policy will _follow_ most packages being bit-for-bit identical, and can't be used as a stick to beat people on the head with. I do not see how this helps. Imagine a build host is compromised and this is noticed only after a few weeks. Theoretically every machine which downloaded and installed a package in this time could be compromised. And even worse: it is practically impossible to find out wether a package is actually affected! Actually, if you do not trust the path down which a binary package flows, you can not use any information down that flow path to test your implementation. You need to do a full source audit, and build from source -- at which point, you might just install your trused binary, instead of trying to verify that the upstream package is the same as yours. If you find this inadequate, then your best bet to seeing this happen is to go ahead and start submitting patches to make package be bit-for-bit compatible -- starting with, perhaps, the essential packages. Once you have enough of the packages converted, we can talk about making this a policy recommendation. I think building gcc builds it several times, and they had a neat trick of ignoring the first few bytes of a file which had the time stamp, and comparing the rest. You could try using that technique to compare files in packages. I, for one, think this technically infeasible, but hey, I'll be happy to be proved wrong. manoj -- There can be no offense where none is taken Japanese proverb Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with exact binary matches
Martin Uecker [EMAIL PROTECTED] writes: If policy would require the exact reproducability of binaries, then it would be a policy violation. You seem to be suggesting that policy should require this *before* it becomes common practice. That's not generally how policy is crafted: Debian policy generally does not prescribe packaging practice, but rather describes it. If some practice is a good idea, the way to see it become policy is to motivate other packagers to follow that practice, until it is common enough that it is not onerous to describe it as packaging policy that should always be followed. Debian policy isn't a stick to beat others with; it's a formal description of packaging practice that is believed to be good independent of being written down in policy. -- \ Any sufficiently advanced bug is indistinguishable from a | `\ feature. -- Rich Kulawiec | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
