Re: Protect against 'guix pull' providing stale data

[Ludovic Courtès]

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’.