* signed tarballs @ 2017-04-06 23:31 Christian Rebischke 2017-04-07 1:27 ` William Roberts ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Christian Rebischke @ 2017-04-06 23:31 UTC (permalink / raw) To: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 286 bytes --] Hello, I am the maintainer of 'audit' in the official Arch Linux Repositories. Is there a reason why you don't provide a signature file for the releases nor a checksum or am I just stupid and can't find it on your website: https://people.redhat.com/sgrubb/audit/ ? Best regards, chris [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-06 23:31 signed tarballs Christian Rebischke @ 2017-04-07 1:27 ` William Roberts 2017-04-07 23:41 ` Christian Rebischke 2017-04-08 12:53 ` Paul Moore 2017-04-10 18:35 ` Steve Grubb 2 siblings, 1 reply; 25+ messages in thread From: William Roberts @ 2017-04-07 1:27 UTC (permalink / raw) To: Christian Rebischke; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 545 bytes --] Why not just checkout the release with git? On Apr 6, 2017 16:36, "Christian Rebischke" <Chris.Rebischke@archlinux.org> wrote: > Hello, > I am the maintainer of 'audit' in the official Arch Linux Repositories. > Is there a reason why you don't provide a signature file for the > releases nor a checksum or am I just stupid and can't find it on your > website: https://people.redhat.com/sgrubb/audit/ ? > > Best regards, > chris > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > [-- Attachment #1.2: Type: text/html, Size: 1127 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-07 1:27 ` William Roberts @ 2017-04-07 23:41 ` Christian Rebischke 2017-04-07 23:52 ` William Roberts 0 siblings, 1 reply; 25+ messages in thread From: Christian Rebischke @ 2017-04-07 23:41 UTC (permalink / raw) To: William Roberts; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 406 bytes --] On Thu, Apr 06, 2017 at 06:27:08PM -0700, William Roberts wrote: > Why not just checkout the release with git? Because this wouldn't solve the problem or do you use signed commits in your linux-audit git repository? And even if you use signed commits I really would appreciate if you would sign the tarball and provide a hash for it on the release page. This would increase security a lot. cheers, chris [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-07 23:41 ` Christian Rebischke @ 2017-04-07 23:52 ` William Roberts 0 siblings, 0 replies; 25+ messages in thread From: William Roberts @ 2017-04-07 23:52 UTC (permalink / raw) To: Christian Rebischke; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 663 bytes --] On Apr 7, 2017 4:41 PM, "Christian Rebischke" <Chris.Rebischke@archlinux.org> wrote: On Thu, Apr 06, 2017 at 06:27:08PM -0700, William Roberts wrote: > Why not just checkout the release with git? Because this wouldn't solve the problem or do you use signed commits in your linux-audit git repository? As long as you use a secure protocol and trust his repo signing the tags doesn't give you all that much. And even if you use signed commits I really would appreciate if you would sign the tarball and provide a hash for it on the release page. This would increase security a lot. Yes agreed there, at least HTTPS connections are available. cheers, chris [-- Attachment #1.2: Type: text/html, Size: 1560 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-06 23:31 signed tarballs Christian Rebischke 2017-04-07 1:27 ` William Roberts @ 2017-04-08 12:53 ` Paul Moore 2017-04-10 18:51 ` Steve Grubb 2017-04-10 18:35 ` Steve Grubb 2 siblings, 1 reply; 25+ messages in thread From: Paul Moore @ 2017-04-08 12:53 UTC (permalink / raw) To: linux-audit On Thu, Apr 6, 2017 at 7:31 PM, Christian Rebischke <Chris.Rebischke@archlinux.org> wrote: > Hello, > I am the maintainer of 'audit' in the official Arch Linux Repositories. > Is there a reason why you don't provide a signature file for the > releases nor a checksum or am I just stupid and can't find it on your > website: https://people.redhat.com/sgrubb/audit/ ? Steve seems to be posting audit userspace releases both on his Red Hat people page and on GitHub; I'm not sure which he considers to be the "authoritative" release, he'll have to answer that. https://github.com/linux-audit/audit-userspace/releases As far as checksum'd and signed releases, someone from the Debian camp recently requested detached signatures for libseccomp and provided the documentation below (it's a short and well done doc). While libseccomp had been signing releases for years, we were using a combined (?) approach, it was relatively easy to add the detached signature. https://wiki.debian.org/Creating%20signed%20GitHub%20releases In case anyone is interested, here is an example of what we now provide for a libseccomp release: https://github.com/seccomp/libseccomp/releases/tag/v2.3.2 ... and the libseccomp release process is documented here: https://github.com/seccomp/libseccomp/blob/master/RELEASE_PROCESS.md -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-08 12:53 ` Paul Moore @ 2017-04-10 18:51 ` Steve Grubb 0 siblings, 0 replies; 25+ messages in thread From: Steve Grubb @ 2017-04-10 18:51 UTC (permalink / raw) To: linux-audit On Saturday, April 8, 2017 8:53:10 AM EDT Paul Moore wrote: > > I am the maintainer of 'audit' in the official Arch Linux Repositories. > > Is there a reason why you don't provide a signature file for the > > releases nor a checksum or am I just stupid and can't find it on your > > website: https://people.redhat.com/sgrubb/audit/ ? > > Steve seems to be posting audit userspace releases both on his Red Hat > people page and on GitHub; I'm not sure which he considers to be the > "authoritative" release, he'll have to answer that. > > https://github.com/linux-audit/audit-userspace/releases I consider the ones from the people page to be authoritative because its been converted from raw, unprocessed development files to a distribution tarball by use of the autotools. This involves running autogen.sh, ./configure, and then make dist-check. Starting with the 2.7.5 release, I changed the naming convention on github to make sure people can tell the difference when looking at the release from the people page vs github. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-06 23:31 signed tarballs Christian Rebischke 2017-04-07 1:27 ` William Roberts 2017-04-08 12:53 ` Paul Moore @ 2017-04-10 18:35 ` Steve Grubb 2017-04-11 10:44 ` Christian Rebischke 2 siblings, 1 reply; 25+ messages in thread From: Steve Grubb @ 2017-04-10 18:35 UTC (permalink / raw) To: linux-audit On Thursday, April 6, 2017 7:31:35 PM EDT Christian Rebischke wrote: > Hello, > I am the maintainer of 'audit' in the official Arch Linux Repositories. > Is there a reason why you don't provide a signature file for the > releases nor a checksum or am I just stupid and can't find it on your > website: https://people.redhat.com/sgrubb/audit/ ? Nobody has ever asked for one. I literally build the package in Fedora within a few minutes of a release. Fedora has hashes of the audit tar file in the "sources" file in the build system in case you want any historical information: http://pkgs.fedoraproject.org/cgit/rpms/audit.git/log/sources -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-10 18:35 ` Steve Grubb @ 2017-04-11 10:44 ` Christian Rebischke 2017-04-11 14:03 ` Steve Grubb 0 siblings, 1 reply; 25+ messages in thread From: Christian Rebischke @ 2017-04-11 10:44 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 669 bytes --] On Mon, Apr 10, 2017 at 02:35:31PM -0400, Steve Grubb wrote: > Nobody has ever asked for one. I literally build the package in Fedora within > a few minutes of a release. Fedora has hashes of the audit tar file in the > "sources" file in the build system in case you want any historical > information: > > http://pkgs.fedoraproject.org/cgit/rpms/audit.git/log/sources > Hello Steve, well.. then I want to ask you if you could use gpg signatures in future for your releases. We, at arch linux, are currently encouraging upstream to use signed releases and https. It's just 5min of work and it's a big step to a more secure internet. Thanks. chris [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-11 10:44 ` Christian Rebischke @ 2017-04-11 14:03 ` Steve Grubb 2017-04-13 20:28 ` Christian Rebischke 0 siblings, 1 reply; 25+ messages in thread From: Steve Grubb @ 2017-04-11 14:03 UTC (permalink / raw) To: Christian Rebischke; +Cc: linux-audit On Tuesday, April 11, 2017 6:44:13 AM EDT Christian Rebischke wrote: > On Mon, Apr 10, 2017 at 02:35:31PM -0400, Steve Grubb wrote: > > Nobody has ever asked for one. I literally build the package in Fedora > > within a few minutes of a release. Fedora has hashes of the audit tar > > file in the "sources" file in the build system in case you want any > > historical information: > > > > http://pkgs.fedoraproject.org/cgit/rpms/audit.git/log/sources > > Hello Steve, > well.. then I want to ask you if you could use gpg signatures in future > for your releases. We, at arch linux, are currently encouraging upstream > to use signed releases and https. It's just 5min of work and it's a big > step to a more secure internet. Thanks. I added a sha256sum to the release announcement yesterday. You can also access the people page via https. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-11 14:03 ` Steve Grubb @ 2017-04-13 20:28 ` Christian Rebischke 2017-04-13 20:30 ` William Roberts 0 siblings, 1 reply; 25+ messages in thread From: Christian Rebischke @ 2017-04-13 20:28 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 318 bytes --] On Tue, Apr 11, 2017 at 10:03:54AM -0400, Steve Grubb wrote: > I added a sha256sum to the release announcement yesterday. You can also access > the people page via https. > Thanks, but as I stated before. SHA256 and https doesn't ensure a non-malicious tarball. Only a signed tarball can achieve this. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 20:28 ` Christian Rebischke @ 2017-04-13 20:30 ` William Roberts 2017-04-13 20:43 ` Steve Grubb 2017-04-13 20:56 ` Christian Rebischke 0 siblings, 2 replies; 25+ messages in thread From: William Roberts @ 2017-04-13 20:30 UTC (permalink / raw) To: Christian Rebischke; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 631 bytes --] On Apr 13, 2017 13:28, "Christian Rebischke" <Chris.Rebischke@archlinux.org> wrote: On Tue, Apr 11, 2017 at 10:03:54AM -0400, Steve Grubb wrote: > I added a sha256sum to the release announcement yesterday. You can also access > the people page via https. > Thanks, but as I stated before. SHA256 and https doesn't ensure a non-malicious tarball. Only a signed tarball can achieve this. That's not true, he's providing you a detached signature via this mechanism. You just need to check the sha256sum before extraction. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit [-- Attachment #1.2: Type: text/html, Size: 1445 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 20:30 ` William Roberts @ 2017-04-13 20:43 ` Steve Grubb 2017-04-13 20:56 ` Christian Rebischke 1 sibling, 0 replies; 25+ messages in thread From: Steve Grubb @ 2017-04-13 20:43 UTC (permalink / raw) To: William Roberts; +Cc: linux-audit On Thursday, April 13, 2017 4:30:57 PM EDT William Roberts wrote: > On Apr 13, 2017 13:28, "Christian Rebischke" <Chris.Rebischke@archlinux.org> > wrote: > > On Tue, Apr 11, 2017 at 10:03:54AM -0400, Steve Grubb wrote: > > I added a sha256sum to the release announcement yesterday. You can also > > access the people page via https. > > Thanks, but as I stated before. SHA256 and https doesn't ensure a > non-malicious tarball. Only a signed tarball can achieve this. > > That's not true, he's providing you a detached signature via this > mechanism. You just need to check the sha256sum before extraction. Yeah, MD5 = collisions. SHA-1 = collisions. SHA-2 no known collisions. NIST found during the SHA-3 competition that SHA-2 was much more robust than previously thought. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 20:30 ` William Roberts 2017-04-13 20:43 ` Steve Grubb @ 2017-04-13 20:56 ` Christian Rebischke 2017-04-13 21:00 ` William Roberts 1 sibling, 1 reply; 25+ messages in thread From: Christian Rebischke @ 2017-04-13 20:56 UTC (permalink / raw) To: William Roberts; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 673 bytes --] On Thu, Apr 13, 2017 at 01:30:57PM -0700, William Roberts wrote: > That's not true, he's providing you a detached signature via this > mechanism. You just need to check the sha256sum before extraction. The problem with providing only a SHA256 hash is that the hash was provide via an insecure channel. I can't be sure that the hash is really from him because he didn't even sign his mails. Someone could spoof his mail or MITM in the webserver with the tarballs, etc etc.. The only secure way to ensure the original content of the tarball is via signed tarballs signed by the developer. Checksums and signed tarballs are totally two different things. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 20:56 ` Christian Rebischke @ 2017-04-13 21:00 ` William Roberts 2017-04-13 21:05 ` Paul Moore 0 siblings, 1 reply; 25+ messages in thread From: William Roberts @ 2017-04-13 21:00 UTC (permalink / raw) To: Christian Rebischke; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 849 bytes --] On Apr 13, 2017 13:56, "Christian Rebischke" <Chris.Rebischke@archlinux.org> wrote: On Thu, Apr 13, 2017 at 01:30:57PM -0700, William Roberts wrote: > That's not true, he's providing you a detached signature via this > mechanism. You just need to check the sha256sum before extraction. The problem with providing only a SHA256 hash is that the hash was provide via an insecure channel. I can't be sure that the hash is really from him because he didn't even sign his mails. Someone could spoof his mail or MITM in the webserver with the tarballs, etc etc.. Isn't the hash on the https people's page? Which last time I looked wasnt throwing cert errors in chrome. The only secure way to ensure the original content of the tarball is via signed tarballs signed by the developer. Checksums and signed tarballs are totally two different things. [-- Attachment #1.2: Type: text/html, Size: 1561 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 21:00 ` William Roberts @ 2017-04-13 21:05 ` Paul Moore 2017-04-13 21:08 ` William Roberts ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Paul Moore @ 2017-04-13 21:05 UTC (permalink / raw) To: William Roberts; +Cc: linux-audit On Thu, Apr 13, 2017 at 5:00 PM, William Roberts <bill.c.roberts@gmail.com> wrote: > Isn't the hash on the https people's page? Which last time I looked wasnt > throwing cert errors in chrome. Unless Steve has exclusive administrative access to people.redhat.com (I think it is safe to say he does not, but correct me if I'm wrong Steve <b>) you can't trust an unsigned checksum regardless of how strong the https cert/crypto as the web admin could still tamper with the data. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 21:05 ` Paul Moore @ 2017-04-13 21:08 ` William Roberts 2017-04-13 21:17 ` Paul Moore 2017-04-13 21:22 ` Christian Rebischke 2017-04-13 22:25 ` Steve Grubb 2 siblings, 1 reply; 25+ messages in thread From: William Roberts @ 2017-04-13 21:08 UTC (permalink / raw) To: Paul Moore; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 700 bytes --] On Apr 13, 2017 14:05, "Paul Moore" <paul@paul-moore.com> wrote: On Thu, Apr 13, 2017 at 5:00 PM, William Roberts <bill.c.roberts@gmail.com> wrote: > Isn't the hash on the https people's page? Which last time I looked wasnt > throwing cert errors in chrome. Unless Steve has exclusive administrative access to people.redhat.com (I think it is safe to say he does not, but correct me if I'm wrong Steve <b>) you can't trust an unsigned checksum regardless of how strong the https cert/crypto as the web admin could still tamper with the data. Sure possible, but not super plausible. You're putting some trust in the administration of that website to begin with. -- paul moore www.paul-moore.com [-- Attachment #1.2: Type: text/html, Size: 1592 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 21:08 ` William Roberts @ 2017-04-13 21:17 ` Paul Moore 2017-04-13 22:39 ` William Roberts 0 siblings, 1 reply; 25+ messages in thread From: Paul Moore @ 2017-04-13 21:17 UTC (permalink / raw) To: William Roberts; +Cc: linux-audit On Thu, Apr 13, 2017 at 5:08 PM, William Roberts <bill.c.roberts@gmail.com> wrote: > On Apr 13, 2017 14:05, "Paul Moore" <paul@paul-moore.com> wrote: >> Unless Steve has exclusive administrative access to people.redhat.com >> (I think it is safe to say he does not, but correct me if I'm wrong >> Steve <b>) you can't trust an unsigned checksum regardless of how >> strong the https cert/crypto as the web admin could still tamper with >> the data. > > Sure possible, but not super plausible. You're putting some trust in the > administration of that website to begin with. Come one man, you're smarter than this :) I only called out the malicious admin case, but there are other cases where someone with malicious intent could tamper with the checksum. Some quick examples: hacked webserver, MITM https proxy, etc. -- paul moore security @ redhat ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 21:17 ` Paul Moore @ 2017-04-13 22:39 ` William Roberts 0 siblings, 0 replies; 25+ messages in thread From: William Roberts @ 2017-04-13 22:39 UTC (permalink / raw) To: Paul Moore; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 1295 bytes --] On Apr 13, 2017 14:17, "Paul Moore" <pmoore@redhat.com> wrote: On Thu, Apr 13, 2017 at 5:08 PM, William Roberts <bill.c.roberts@gmail.com> wrote: > On Apr 13, 2017 14:05, "Paul Moore" <paul@paul-moore.com> wrote: >> Unless Steve has exclusive administrative access to people.redhat.com >> (I think it is safe to say he does not, but correct me if I'm wrong >> Steve <b>) you can't trust an unsigned checksum regardless of how >> strong the https cert/crypto as the web admin could still tamper with >> the data. > > Sure possible, but not super plausible. You're putting some trust in the > administration of that website to begin with. Come one man, you're smarter than this :) I only called out the malicious admin case, but there are other cases where someone with malicious intent could tamper with the checksum. Some quick examples: hacked webserver, MITM https proxy, etc. It's all about trust, I could sign my tarballs and plop the private key somewhere dumb. This is why pki is hard. There's always flaws, I consider https + hash to be like a medium level of trust, and definitely an improvement over nothing. Nothing will beat a signed blob, and we'll assume Steve uses a smart card stored in a vault and only ever used for signing releases with. -- paul moore security @ redhat [-- Attachment #1.2: Type: text/html, Size: 2305 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 21:05 ` Paul Moore 2017-04-13 21:08 ` William Roberts @ 2017-04-13 21:22 ` Christian Rebischke 2017-04-13 22:45 ` William Roberts 2017-04-13 22:25 ` Steve Grubb 2 siblings, 1 reply; 25+ messages in thread From: Christian Rebischke @ 2017-04-13 21:22 UTC (permalink / raw) To: Paul Moore; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 1923 bytes --] On Thu, Apr 13, 2017 at 05:05:36PM -0400, Paul Moore wrote: > Unless Steve has exclusive administrative access to people.redhat.com > (I think it is safe to say he does not, but correct me if I'm wrong > Steve <b>) you can't trust an unsigned checksum regardless of how > strong the https cert/crypto as the web admin could still tamper with > the data. We are not only talking about the web admin. We live in times where governments can easily tamper such data and the documents from snowden and some other whistleblowers prove that they did stuff like this. The only way to make sure that the tarball is the original tarball is with a signature from Steve grubbs gpg-key. This would ensure that steve has checked the content. Just imagine the following scenario: 1. New audit version 2. Steve uploads the new version with new hash to the webserver. 3. Let's imagine that hackers would MITM my connection or modify the server content. They could deploy a new tarball and generate a new checksum for it, because SHA256 is just *one* factor. Everyone who would download the new tarball would check against the new malicious hash. This is a valid attack scenario.. This scenario could only be prevent by using signed tarballs. Because people like me and other distribution maintainers would have Steves pubkey. If somebody would modify the tarball he would need Steves pubkey. And this is much more difficult than just MITM the connection or tampering the data on the webserver. With a signed tarball the attacker would have following problems: 1. the attacker can't deploy a malicious tarball without signature, because this would make clear that the tarball is malicious. 2. if the attacker would generate an own signature for the maliciois tarball, people who verify the tarball would get a warning because the key is unknown and not part of steves keyring. I hope this email is clearer... Thanks for reading. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 21:22 ` Christian Rebischke @ 2017-04-13 22:45 ` William Roberts 2017-04-13 23:17 ` Steve Grubb 0 siblings, 1 reply; 25+ messages in thread From: William Roberts @ 2017-04-13 22:45 UTC (permalink / raw) To: Christian Rebischke; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 2464 bytes --] On Apr 13, 2017 14:22, "Christian Rebischke" <Chris.Rebischke@archlinux.org> wrote: On Thu, Apr 13, 2017 at 05:05:36PM -0400, Paul Moore wrote: > Unless Steve has exclusive administrative access to people.redhat.com > (I think it is safe to say he does not, but correct me if I'm wrong > Steve <b>) you can't trust an unsigned checksum regardless of how > strong the https cert/crypto as the web admin could still tamper with > the data. We are not only talking about the web admin. We live in times where governments can easily tamper such data and the documents from snowden and some other whistleblowers prove that they did stuff like this. The only way to make sure that the tarball is the original tarball is with a signature from Steve grubbs gpg-key. This would ensure that steve has checked the content. Just imagine the following scenario: 1. New audit version 2. Steve uploads the new version with new hash to the webserver. 3. Let's imagine that hackers would MITM my connection or modify the server content. They could deploy a new tarball and generate a new checksum for it, because SHA256 is just *one* factor. Everyone who would download the new tarball would check against the new malicious hash. This is a valid attack scenario.. This scenario could only be prevent by using signed tarballs. Because people like me and other distribution maintainers would have Steves pubkey. If somebody would modify the tarball he would need Steves pubkey. And this is much more difficult than just MITM the connection or tampering the data on the webserver. With a signed tarball the attacker would have following problems: 1. the attacker can't deploy a malicious tarball without signature, because this would make clear that the tarball is malicious. 2. if the attacker would generate an own signature for the maliciois tarball, people who verify the tarball would get a warning because the key is unknown and not part of steves keyring. I hope this email is clearer... You're assuming a lot for an attack to happen, and your assuming a state of steves security of his key, his repo, etc at release time. Pki is based on trust of confidentiality of the private key. If Steve starts signing the tarballs, it would be great (everyone should), but https + hash is better then nothing, that's my point. The difference really boils down to trust of the key, admin vs Steve. Admin vs Steve is much better than united vs Steve ;-). Thanks for reading. [-- Attachment #1.2: Type: text/html, Size: 3403 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 22:45 ` William Roberts @ 2017-04-13 23:17 ` Steve Grubb 0 siblings, 0 replies; 25+ messages in thread From: Steve Grubb @ 2017-04-13 23:17 UTC (permalink / raw) To: linux-audit On Thursday, April 13, 2017 6:45:55 PM EDT William Roberts wrote: > On Apr 13, 2017 14:22, "Christian Rebischke" <Chris.Rebischke@archlinux.org> > wrote: > > On Thu, Apr 13, 2017 at 05:05:36PM -0400, Paul Moore wrote: > > Unless Steve has exclusive administrative access to people.redhat.com > > (I think it is safe to say he does not, but correct me if I'm wrong > > Steve <b>) you can't trust an unsigned checksum regardless of how > > strong the https cert/crypto as the web admin could still tamper with > > the data. > > We are not only talking about the web admin. We live in times where > governments can easily tamper such data and the documents from snowden > and some other whistleblowers prove that they did stuff like this. > > The only way to make sure that the tarball is the original tarball is > with a signature from Steve grubbs gpg-key. This would ensure that steve > has checked the content. > > Just imagine the following scenario: > > 1. New audit version > 2. Steve uploads the new version with new hash to the webserver. > > 3. Let's imagine that hackers would MITM my connection or modify the > server content. They could deploy a new tarball and generate a new > checksum for it, because SHA256 is just *one* factor. Everyone who would > download the new tarball would check against the new malicious hash. > > This is a valid attack scenario.. This scenario could only be prevent by > using signed tarballs. Because people like me and other distribution > maintainers would have Steves pubkey. If somebody would modify the > tarball he would need Steves pubkey. And this is much more difficult > than just MITM the connection or tampering the data on the webserver. > > With a signed tarball the attacker would have following problems: > > 1. the attacker can't deploy a malicious tarball without signature, > because this would make clear that the tarball is malicious. > 2. if the attacker would generate an own signature for the maliciois > tarball, people who verify the tarball would get a warning because the > key is unknown and not part of steves keyring. > > I hope this email is clearer... > > > You're assuming a lot for an attack to happen, and your assuming a state of > steves security of his key, his repo, etc at release time. Pki is based on > trust of confidentiality of the private key. If Steve starts signing the > tarballs, it would be great (everyone should), but https + hash is better > then nothing, that's my point. The difference really boils down to trust of > the key, admin vs Steve. Admin vs Steve is much better than united vs Steve > ;-). Indeed. I think the most plausible issue anyone would ever run across is the bugs that I may have inadvertently put in the code base rather than a MITM at the very second a distro is downloading a new release. How closely is anyone checking this code? Any fuzzers? Static analysis? Test suites? :-) I understand the desire for source integrity. We'll go with hashes now and work up to signing another day. Meanwhile...how about some bug reports? Trust me. They are there. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 21:05 ` Paul Moore 2017-04-13 21:08 ` William Roberts 2017-04-13 21:22 ` Christian Rebischke @ 2017-04-13 22:25 ` Steve Grubb 2017-04-14 13:06 ` Paul Moore 2 siblings, 1 reply; 25+ messages in thread From: Steve Grubb @ 2017-04-13 22:25 UTC (permalink / raw) To: linux-audit On Thursday, April 13, 2017 5:05:36 PM EDT Paul Moore wrote: > On Thu, Apr 13, 2017 at 5:00 PM, William Roberts > > <bill.c.roberts@gmail.com> wrote: > > Isn't the hash on the https people's page? No, its on the mail list. The mail list is moderated. Only a handful of people could post a spoofed message. > > Which last time I looked wasnt throwing cert errors in chrome. > > Unless Steve has exclusive administrative access to people.redhat.com > (I think it is safe to say he does not, but correct me if I'm wrong > Steve <b>) Nope. > you can't trust an unsigned checksum regardless of how > strong the https cert/crypto as the web admin could still tamper with > the data. They would have to go tamper with the mail list where all the hashes are publicly disclosed, too. There are multiple mail list archives. Then they would have to post the tampered tarball to the Fedora Build System which also publicly discloses hashs. And the Fedora Build System requires several identity checks to check it in and it maintains a log. You might get one, but you can't get them all. I'd say just a simple check of the hash would catch most problems. If not, then I'd trust what's in Fedora over the people page. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-13 22:25 ` Steve Grubb @ 2017-04-14 13:06 ` Paul Moore 2017-04-14 13:38 ` Steve Grubb 0 siblings, 1 reply; 25+ messages in thread From: Paul Moore @ 2017-04-14 13:06 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit On Thu, Apr 13, 2017 at 6:25 PM, Steve Grubb <sgrubb@redhat.com> wrote: > On Thursday, April 13, 2017 5:05:36 PM EDT Paul Moore wrote: >> On Thu, Apr 13, 2017 at 5:00 PM, William Roberts >> >> <bill.c.roberts@gmail.com> wrote: >> > Isn't the hash on the https people's page? > > No, its on the mail list. The mail list is moderated. Only a handful of people > could post a spoofed message. > >> > Which last time I looked wasnt throwing cert errors in chrome. >> >> Unless Steve has exclusive administrative access to people.redhat.com >> (I think it is safe to say he does not, but correct me if I'm wrong >> Steve <b>) > > Nope. > >> you can't trust an unsigned checksum regardless of how >> strong the https cert/crypto as the web admin could still tamper with >> the data. > > They would have to go tamper with the mail list where all the hashes are > publicly disclosed, too. There are multiple mail list archives. Then they > would have to post the tampered tarball to the Fedora Build System which also > publicly discloses hashs. And the Fedora Build System requires several > identity checks to check it in and it maintains a log. No. Since there is no authentication to post to this public email list all they would have to do is spoof bogus a release announcement email from you; yes there are some measures in place to combat things like this, but it isn't that hard. Granted, you might notice this attack relatively quickly, but if the attack was timed to happen while you were away from your email for an extended period of time (travel, etc.) the window could be non-trivial, and even then, how many installs could have already been put at risk? Steve, it's pretty apparent at this point that you don't want to, and aren't likely to, provide any form of signed checksum for the audit userspace release. That's your prerogative, and to some like William, they may be content with that level of risk. However, please don't pretend that signing releases doesn't provide an additional layer of protection. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-14 13:06 ` Paul Moore @ 2017-04-14 13:38 ` Steve Grubb 2017-04-14 23:03 ` Christian Rebischke 0 siblings, 1 reply; 25+ messages in thread From: Steve Grubb @ 2017-04-14 13:38 UTC (permalink / raw) To: Paul Moore; +Cc: linux-audit On Friday, April 14, 2017 9:06:53 AM EDT Paul Moore wrote: > On Thu, Apr 13, 2017 at 6:25 PM, Steve Grubb <sgrubb@redhat.com> wrote: > > On Thursday, April 13, 2017 5:05:36 PM EDT Paul Moore wrote: > >> On Thu, Apr 13, 2017 at 5:00 PM, William Roberts > >> > >> <bill.c.roberts@gmail.com> wrote: > >> > Isn't the hash on the https people's page? > > > > No, its on the mail list. The mail list is moderated. Only a handful of > > people could post a spoofed message. > > > >> > Which last time I looked wasnt throwing cert errors in chrome. > >> > >> Unless Steve has exclusive administrative access to people.redhat.com > >> (I think it is safe to say he does not, but correct me if I'm wrong > >> Steve <b>) > > > > Nope. > > > >> you can't trust an unsigned checksum regardless of how > >> strong the https cert/crypto as the web admin could still tamper with > >> the data. > > > > They would have to go tamper with the mail list where all the hashes are > > publicly disclosed, too. There are multiple mail list archives. Then they > > would have to post the tampered tarball to the Fedora Build System which > > also publicly discloses hashs. And the Fedora Build System requires > > several identity checks to check it in and it maintains a log. > > No. Since there is no authentication to post to this public email > list all they would have to do is spoof bogus a release announcement > email from you; yes there are some measures in place to combat things > like this, but it isn't that hard. Granted, you might notice this > attack relatively quickly, but if the attack was timed to happen while > you were away from your email for an extended period of time (travel, > etc.) the window could be non-trivial, and even then, how many > installs could have already been put at risk? > > Steve, it's pretty apparent at this point that you don't want to, and > aren't likely to, provide any form of signed checksum for the audit > userspace release. That's your prerogative, and to some like William, > they may be content with that level of risk. However, please don't > pretend that signing releases doesn't provide an additional layer of > protection. As I said in a subsequent email, "we'll go with hashes now and work up to signing another day." But I really am serious that the biggest threat to the project is not some wild eyed MITM attack targeting a whole distribution. Its me. I doubt few people truly understand the impact of the bug that Laurent reported and why it moved me to change plans and do a quick release. (It was not because ausearch was segfaulting.) Again, I call for more testing and bug reports. I know they are in the code. I find a couple every day or two. -Steve ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: signed tarballs 2017-04-14 13:38 ` Steve Grubb @ 2017-04-14 23:03 ` Christian Rebischke 0 siblings, 0 replies; 25+ messages in thread From: Christian Rebischke @ 2017-04-14 23:03 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 829 bytes --] On Fri, Apr 14, 2017 at 09:38:51AM -0400, Steve Grubb wrote: > As I said in a subsequent email, "we'll go with hashes now and > work up to signing another day." But I really am serious that the biggest > threat to the project is not some wild eyed MITM attack targeting a whole > distribution. Its me. I doubt few people truly understand the impact of the > bug that Laurent reported and why it moved me to change plans and do a quick > release. (It was not because ausearch was segfaulting.) Again, I call for more > testing and bug reports. I know they are in the code. I find a couple every > day or two. Yep, the first factor is the code. But keep in mind that signing tarballs are just 5 minutes of work per release. I see no reason why audit shouldn't do it, all other redhat projects do it too. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2017-04-14 23:03 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-06 23:31 signed tarballs Christian Rebischke 2017-04-07 1:27 ` William Roberts 2017-04-07 23:41 ` Christian Rebischke 2017-04-07 23:52 ` William Roberts 2017-04-08 12:53 ` Paul Moore 2017-04-10 18:51 ` Steve Grubb 2017-04-10 18:35 ` Steve Grubb 2017-04-11 10:44 ` Christian Rebischke 2017-04-11 14:03 ` Steve Grubb 2017-04-13 20:28 ` Christian Rebischke 2017-04-13 20:30 ` William Roberts 2017-04-13 20:43 ` Steve Grubb 2017-04-13 20:56 ` Christian Rebischke 2017-04-13 21:00 ` William Roberts 2017-04-13 21:05 ` Paul Moore 2017-04-13 21:08 ` William Roberts 2017-04-13 21:17 ` Paul Moore 2017-04-13 22:39 ` William Roberts 2017-04-13 21:22 ` Christian Rebischke 2017-04-13 22:45 ` William Roberts 2017-04-13 23:17 ` Steve Grubb 2017-04-13 22:25 ` Steve Grubb 2017-04-14 13:06 ` Paul Moore 2017-04-14 13:38 ` Steve Grubb 2017-04-14 23:03 ` Christian Rebischke
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.