From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: signed tarballs Date: Thu, 13 Apr 2017 19:17:41 -0400 Message-ID: <3984048.ybg3X6gWBZ@x2> References: <20170406233134.GA32113@motoko> <20170413212203.GB19785@motoko> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday, April 13, 2017 6:45:55 PM EDT William Roberts wrote: > On Apr 13, 2017 14:22, "Christian Rebischke" > 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 ) 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