help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix and remote trust


From: Pierre Neidhardt
Subject: Re: Guix and remote trust
Date: Fri, 13 Dec 2019 14:18:46 +0100

zimoun <address@hidden> writes:

> Hi Pierre,
>
> On Fri, 13 Dec 2019 at 13:24, Pierre Neidhardt <address@hidden> wrote:
>
>> >  1. check the integrity on the balaitou machine by running "guix gc 
>> > --verify"
>>
>> I'm not sure this works because if `guix' itself is compromised,
>> `guix gc --verify' becomes irrelevant.  Or is there another way?
>
> Ok. And so?
> It means that some hashes will differ between the hashes on aneto (you
> trust) and balaitou (compromised).
> It is not possible to "guix gc --verify" two machines and to obtain
> all the same hashes. Or it means that the "attacker" is doing
> hash-collision...

OK, but why did you mention "guix gc --verify" in the first place?  How
can it help here?

> Your point is to check if balaitou is compromised, right?
> The goal of "guix publish" is not to install or serve substitutes, it
> is just to publicly expose what we trust.
> Whatever from where comes from the binary (substitutes, local build, etc.).

Maybe there is a misunderstanding here.  I meant the we can only perform
the check from Aneto, because we don't trust Balaitou.

The following would not work:

- On Aneto: run guix publish.
- On Balaitou: Install packages using Aneto's trusted packages.

This does not work because the "guix" on Balaitou could very well lie
about what it gets, or even directly compromise what it gets.

>> This seems like a good option.  In particular, this should verify "guix"
>> itself, and thus everything else.
>
> Without the "guix publish" on aneto, it is hard to "guix challenge" on 
> balaitou

But you can't run "guix challenge" on balaitou because you can't trust
"guix" there.  It could very well "pass the challenge" while in reality
be compromised.

>> So I'd reverse your point.  By first challenging Balaitou, we can trust
>> the guix executable and from there we can run 1. and 2.
>
> Yes, if you have root access and network control on balaitou, you can
> expose it ("guix publish").
> Then Alice will "guix challenge" her own store (on aneto) against the
> balaitou one.

Yes, this seems correct.

>> Thoughts?
>
> The only issue is that "guix challenge" works with local builds.
> So Alice needs to locally build everything used on balaitou.
> I am imagining that aneto is the Alice's laptop and balaitou a server.

Yes.

> So, Alice could populate the aneto store using substitutes (from
> ci.guix.gnu.org) for example. And then publishing the result.
> And the server balaitou can build what Alice wants to use on balaitou.

As mentioned above, I don't think this works because we can't trust
"guix" on balaitou.

The other way around would work (with root access): build everything on
balaitou, guix publish there, then run "guix challenge" on Aneto.

Let me know if I'm incorrect! :)

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]