signed tarballs

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

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

On Apr 7, 2017 4:41 PM, "Christian Rebischke" <[email protected]> wrote:

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

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

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

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

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

I added a sha256sum to the release announcement yesterday. You can also access the people page via https.

-Steve

Thanks, but as I stated before. SHA256 and https doesn't ensure a non-malicious tarball. Only a signed tarball can achieve this.

On Apr 13, 2017 13:28, "Christian Rebischke" <[email protected]> wrote:

access

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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

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

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.

On Apr 13, 2017 13:56, "Christian Rebischke" <[email protected]> wrote:

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.

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

On Apr 13, 2017 14:05, "Paul Moore" <[email protected]> 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.

--
paul moore
www.paul-moore.com

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

On Apr 13, 2017 14:17, "Paul Moore" <[email protected]> wrote:

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

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.

On Apr 13, 2017 14:22, "Christian Rebischke" <[email protected]> wrote:

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.

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

No, its on the mail list. The mail list is moderated. Only a handful of people could post a spoofed message.

Nope.

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

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

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

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.