Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-audit@redhat.com
Subject: Re: signed tarballs
Date: Fri, 14 Apr 2017 09:38:51 -0400	[thread overview]
Message-ID: <6911467.0fbbL1krjI@x2> (raw)
In-Reply-To: <CAHC9VhSFaw4knZQqJfds8ci06n6CUmiXjW87KiA-9YnLc5To9Q@mail.gmail.com>

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

  reply	other threads:[~2017-04-14 13:38 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
2017-04-13 22:25                 ` Steve Grubb
2017-04-14 13:06                   ` Paul Moore
2017-04-14 13:38                     ` Steve Grubb [this message]
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=6911467.0fbbL1krjI@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=paul@paul-moore.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