[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protect against 'guix pull' providing stale data
From: |
Simon Josefsson |
Subject: |
Protect against 'guix pull' providing stale data |
Date: |
Tue, 07 Feb 2023 09:14:18 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi all,
I was watching
https://fosdem.org/2023/schedule/event/security_where_does_that_code_come_from/
and one concern that came up was that there is no protection or
mitigation against 'guix pull' servers providing machines old data, to
(for example) stall security updates from reaching a server. Currently
the Savannah sysadmins have the power to delay security updates for my
machine. I think this should be considered a unwanted behaviour that
warrant some action, either tooling improvement or documentation.
There are many ways to improve the situation, even though addressing the
problem completely is difficult (most if not all GNU/Linux distributions
have similar issues). Some ideas:
* Warn if the repository has not since a commit for > 7 days, with the
delay being configurable. This may be a bad idea: warnings are
generally not appreciated by users, security warnings specially so.
* Have 'guix pull' show metadata for the last commit it received (e.g.,
show output from: git log -1) to give users a way of noticing that it
is not seeing new data. Currently only the git commit id is shown
which does not convey enough information.
* Adopt a way for repositories to state the validity period of its
content to have the 7 days a bit configurable, compare for example:
https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until
The idea being that 'guix pull' would fail if the repository hasn't
been touched after the specified interval end, causing the user notice
and take action. The maximum interval provided by the repository
should probably be limited by a locally configured maximum delay the
user is willing to only see old data.
This brings up other concerns (what if someone steals an OpenPGP
signing key and changes it to 70000 days and pushes that out to one
machine only based on IP address, and then stalls that machine from
updating again) but it seems to provide decent user experience and
some good protection by default. Protecting against OpenPGP key
breaches can be mitigated by other means, and shouldn't be a strong
argument this improvement to stale servers.
* Have a third party, or even decentralized system, monitoring service
where each client can compare the commit data they got from 'guix
pull' with what everyone else is seeing. This provides global
consistency of what Guix machines are seeing for the Guix
repositories, similar to Certificate Transparency. This protect
against targetted stale data attacks only, but that may be sufficient:
any non-targetted stale data attack is likely to be noticed by Guix
maintainers.
This would also protect against substitution attacks, although I'm not
sure if Guix protects against them by other means? I'm thinking a
malicious savannah could send me core-updates instead of master, but
call it master to my machine, and I'll not notic that I got a
different branch instead. Does 'guix authenticate' verify meta-data
such as git branch in a way where the server cannot fake this data?
There are many other ideas too.
Thoughts?
/Simon
signature.asc
Description: PGP signature
- Protect against 'guix pull' providing stale data,
Simon Josefsson <=