From: Simon Josefsson via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: guix-devel@gnu.org
Subject: Protect against 'guix pull' providing stale data
Date: Tue, 07 Feb 2023 09:14:18 +0100 [thread overview]
Message-ID: <87cz6lzycl.fsf@kaka.sjd.se> (raw)
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]
next reply other threads:[~2023-02-07 8:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 8:14 Simon Josefsson via Development of GNU Guix and the GNU System distribution. [this message]
2023-02-08 9:31 ` Protect against 'guix pull' providing stale data Ludovic Courtès
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=87cz6lzycl.fsf@kaka.sjd.se \
--to=guix-devel@gnu.org \
--cc=simon@josefsson.org \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.