* Protect against 'guix pull' providing stale data
@ 2023-02-07 8:14 Simon Josefsson via Development of GNU Guix and the GNU System distribution.
2023-02-08 9:31 ` Ludovic Courtès
0 siblings, 1 reply; 2+ messages in thread
From: Simon Josefsson via Development of GNU Guix and the GNU System distribution. @ 2023-02-07 8:14 UTC (permalink / raw)
To: guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Protect against 'guix pull' providing stale data
2023-02-07 8:14 Protect against 'guix pull' providing stale data Simon Josefsson via Development of GNU Guix and the GNU System distribution.
@ 2023-02-08 9:31 ` Ludovic Courtès
0 siblings, 0 replies; 2+ messages in thread
From: Ludovic Courtès @ 2023-02-08 9:31 UTC (permalink / raw)
To: Simon Josefsson via Development of GNU Guix and the GNU System distribution.
Cc: Simon Josefsson
Hi Simon!
Simon Josefsson via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> skribis:
> 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.
Right, it’s a limitation of this model (and of Git in general). This is
mentioned in <https://doi.org/10.22152/programming-journal.org/2023/7/1>
(Section 7 discusses that in the context of mirrors, and Related Work
mentions the “reference state log” mechanism proposed by Torres-Arias et
al.).
> 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.
Yeah.
> * 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.
Right, but commit timestamps wouldn’t help either: with the current
backlog, we regularly push one-month-old patches. :-) Expecting users
to judge freshness on their own doesn’t sound piratical to me anyway.
> * 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.
How would you communicate that validity period to clients though? One
could use a HTTP header but I don’t think Git clients (libgit2 in this
case) pay attention to that.
[...]
> * 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.
I think non-targeted stale data attacks (i.e., attacks on the primary
Git repo) would be detected by Guix committers promptly. So in fact,
I’m not that concerned about this one. And then there’s protection
about stale mirrors, too.
As for targeted attacks, where one would essentially trick a person into
talking to git.evil.com instead of git.sv.gnu.org and fetching a stale
repo from there, I don’t know. The “reference state log” mechanism can
address that IIRC, but it requires modifications to Git clients and
servers.
Some sort of Commit Transparency log sounds interesting, but it also
raises the issue of what trust to put into that log (what to do when the
transparency log and the repo disagree?).
> 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?
‘guix git authenticate’ only checks the “authorization invariant”.
The article above also mentions “teleport attacks”, which are not
addressed per se. There was a discussion with Maxime Devos describing
an attack whereby the attack would change ‘master’ to point to the
‘core-updates’ branch, which in practice could lead users to download
stale packages, as discussed in Section 6:
<https://issues.guix.gnu.org/48146>
There’s no easy way to address that, but it’s also no very practical in
Guix.
Thanks for your feedback and for organizing the devroom!
Ludo’.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-02-08 10:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-07 8:14 Protect against 'guix pull' providing stale data Simon Josefsson via Development of GNU Guix and the GNU System distribution.
2023-02-08 9:31 ` Ludovic Courtès
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.