Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upLog hash of each package going to be installed during template build #2524
Comments
marmarek
added
C: builder
enhancement
P: major
labels
Dec 17, 2016
marmarek
added this to the Release 4.0 milestone
Dec 17, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Dec 17, 2016
Member
I've implemented this for Debian already:
- QubesOS/qubes-builder-debian@f1e2283
- QubesOS/qubes-builder-debian@a8b7cd1
- QubesOS/qubes-builder-debian@0408d55
Example build log: https://raw.githubusercontent.com/QubesOS/build-logs/master/release/release_2016-12-17_16-33-43
Other distributions (at least Fedora) still pending.
|
I've implemented this for Debian already:
Example build log: https://raw.githubusercontent.com/QubesOS/build-logs/master/release/release_2016-12-17_16-33-43 Other distributions (at least Fedora) still pending. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Dec 18, 2016
Member
This is an excellent idea.
-
Could it be extended to apply to packages that users install in templates?
-
Could it be paired with a system that uploads the hashes somewhere (if the user opts in), so that everyone's hashes can be compared automatically?
|
This is an excellent idea.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Jan 6, 2017
I realize its not the only reason to have a logging function while building templates, but isn't CVE-2016-1252 about a bug in NTP? The fact that OpenSSL was involved seems tangential. It does not refer to verification code contained within a crypto tool and has nothing to do with GPG.
I mention this because Andrew referred to this issue in qubes-devel as inspiration for a hash-based scheme for dom0 updates about which I have reservations.
tasket
commented
Jan 6, 2017
|
I realize its not the only reason to have a logging function while building templates, but isn't CVE-2016-1252 about a bug in NTP? The fact that OpenSSL was involved seems tangential. It does not refer to verification code contained within a crypto tool and has nothing to do with GPG. I mention this because Andrew referred to this issue in qubes-devel as inspiration for a hash-based scheme for dom0 updates about which I have reservations. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jan 7, 2017
Member
but isn't CVE-2016-1252 about a bug in NTP?
No, it's apt bug: https://security-tracker.debian.org/tracker/CVE-2016-1252
No, it's apt bug: https://security-tracker.debian.org/tracker/CVE-2016-1252 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Jan 7, 2017
Member
I realize its not the only reason to have a logging function while building templates, but isn't CVE-2016-1252 about a bug in NTP? The fact that OpenSSL was involved seems tangential. It does not refer to verification code contained within a crypto tool and has nothing to do with GPG.
As Marek said, it's the recent APT bug for which we published QSB 28.
As Marek said, it's the recent APT bug for which we published QSB 28. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Done for Fedora too. |
marmarek commentedDec 17, 2016
Currently template build process rely on digital signature verification of all downloaded components. This is expected to be done by appropriate package manager. But attacker who control distribution signing key, or found a bug in signature verification code (like CVE-2016-1252) may try to perform targeted attack against specifically template build process. Currently we mitigate this kind of targeted attacks by downloading all the components through tor. This force the attacker to expose infected packages to wider community to have successful attack, but also increase the risk of being caught.
We'd like to extend this process by logging hash of each downloaded package, before it has a chance to compromise logging component itself (so, before being extracted, before executing any script from inside of it). Thanks to #2023 we may have reasonably protected append-only build log of templates.
The missing part is actual logging the hashes. This should be implemented by each builder plugin separately, as it is specific to package manager running there.