6:31 p.m.
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
8:27 p.m.
Why not just checkout the release with git?
On Apr 6, 2017 16:36, "Christian Rebischke"
<Chris.Rebischke(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
6:41 p.m.
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
6:52 p.m.
On Apr 7, 2017 4:41 PM, "Christian Rebischke"
<Chris.Rebischke(a)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
7:53 a.m.
On Thu, Apr 6, 2017 at 7:31 PM, Christian Rebischke
<Chris.Rebischke(a)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
1:51 p.m.
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
1:35 p.m.
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
5:44 a.m.
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
9:03 a.m.
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
3:28 p.m.
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.
3:30 p.m.
On Apr 13, 2017 13:28, "Christian Rebischke"
<Chris.Rebischke(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
3:43 p.m.
On Thursday, April 13, 2017 4:30:57 PM EDT William Roberts wrote:
On Apr 13, 2017 13:28, "Christian Rebischke"
<Chris.Rebischke(a)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
3:56 p.m.
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.
4 p.m.
On Apr 13, 2017 13:56, "Christian Rebischke"
<Chris.Rebischke(a)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.
4:05 p.m.
On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
<bill.c.roberts(a)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
4:08 p.m.
On Apr 13, 2017 14:05, "Paul Moore" <paul(a)paul-moore.com> wrote:
On Thu, Apr 13, 2017 at 5:00 PM, William Roberts
<bill.c.roberts(a)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
4:17 p.m.
On Thu, Apr 13, 2017 at 5:08 PM, William Roberts
<bill.c.roberts(a)gmail.com> wrote:
On Apr 13, 2017 14:05, "Paul Moore"
<paul(a)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
5:39 p.m.
On Apr 13, 2017 14:17, "Paul Moore" <pmoore(a)redhat.com> wrote:
On Thu, Apr 13, 2017 at 5:08 PM, William Roberts
<bill.c.roberts(a)gmail.com> wrote:
On Apr 13, 2017 14:05, "Paul Moore"
<paul(a)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
4:22 p.m.
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.
5:45 p.m.
On Apr 13, 2017 14:22, "Christian Rebischke"
<Chris.Rebischke(a)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.
6:17 p.m.
On Thursday, April 13, 2017 6:45:55 PM EDT William Roberts wrote:
On Apr 13, 2017 14:22, "Christian Rebischke"
<Chris.Rebischke(a)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
5:25 p.m.
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(a)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
8:06 a.m.
On Thu, Apr 13, 2017 at 6:25 PM, Steve Grubb <sgrubb(a)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(a)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
8:38 a.m.
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(a)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(a)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
6:03 p.m.
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.
2809
days inactive
2817
days old
linux-audit@lists.linux-audit.osci.io
24 comments
5 participants
participants (5)
-
Christian Rebischke -
Paul Moore -
Paul Moore -
Steve Grubb -
William Roberts