Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: signed tarballs
Date: Thu, 13 Apr 2017 19:17:41 -0400	[thread overview]
Message-ID: <3984048.ybg3X6gWBZ@x2> (raw)
In-Reply-To: <CAFftDdqb9zkh=QjMsm4npEqTMXX8PqQ3OnxoUwqE7FYVXS039g@mail.gmail.com>

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

  reply	other threads:[~2017-04-13 23:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3984048.ybg3X6gWBZ@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox