Guix and remote trust

Guix and remote trust

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

Hi!

Guix gives lots of guarantees locally: packages can be --check'ed,
profiles are reproducible, etc.

I am wondering whether Guix can still provide more guarantees than
non-functional package managers / OS when running on a remote machine
(controlled by an non-trusted third-party) with, say, SSH root access.

For instance, can we somehow have the guarantee that the remote machine
is the Guix we installed and hasn't been tampered with?

I'm not sure whether I'm asking something trivial or not.  If the
latter, I'd be happy to read more literature about it.

What do you people know on the topic?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix and remote trust

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]


Pierre Neidhardt <mail@ambrevar.xyz> writes:

> I am wondering whether Guix can still provide more guarantees than
> non-functional package managers / OS when running on a remote machine
> (controlled by an non-trusted third-party) with, say, SSH root access.
>
> For instance, can we somehow have the guarantee that the remote machine
> is the Guix we installed and hasn't been tampered with?
>
> I'm not sure whether I'm asking something trivial or not.  If the
> latter, I'd be happy to read more literature about it.
>
> What do you people know on the topic?

This sounds like guix gc --verify=contents. Debian has a similar feature
I think, with dpkg --verify.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: Guix and remote trust

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> This sounds like guix gc --verify=contents. Debian has a similar feature
> I think, with dpkg --verify.

From the manual:

--8<---------------cut here---------------start------------->8---
     When passing ‘--verify=contents’, the daemon computes the content
     hash of each store item and compares it against its hash in the
     database.  Hash mismatches are reported as data corruptions.
     Because it traverses _all the files in the store_, this command can
     take a long time, especially on systems with a slow disk drive.
--8<---------------cut here---------------end--------------->8---

Is this still relevant remotely?  If an untrusted third-party has root
access to the system, they can probably tamper with both the database
and the store, right?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix and remote trust

[zimoun]

Hi Pierre,

Sorry if I am dumb but I do not understand what is your use-case and
what you try to achieve.

I imagine... so maybe I am totally out of your scope.

Let consider Alice and Bob and 2 machines: aneto and balaitou.
Alice runs aneto, it is her local machine.
And she has an SSH access to balitou. And say this access is non-root,
only Bob has root access on balaitou.

Your question is: how can Alice be sure that she runs the same
binaries on aneto and balaitou? other said how can she detect baloitou
has been compromised?
Is it your use-case?

If yes, Alice can :

 1. check the integrity on the balaitou machine by running "guix gc --verify"
 2. publish the store of aneto with "guix publish"
 3. challenge the store of balaitou against the store of aneto with
"guix challenge"

Does not fit your use-case?


Cheers,
simon

Re: Guix and remote trust

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> Your question is: how can Alice be sure that she runs the same
> binaries on aneto and balaitou? other said how can she detect baloitou
> has been compromised?
> Is it your use-case?

Yes, you got it right! :)

> If yes, Alice can :
>
>  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?

>  2. publish the store of aneto with "guix publish"

And then install packages from balaitou?  But if Balaitou's "guix" is
compromised, it does not matter that the substitute server is trusted.

Or did you mean something else?

>  3. challenge the store of balaitou against the store of aneto with
> "guix challenge"

This seems like a good option.  In particular, this should verify "guix"
itself, and thus everything else.


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.

Thoughts?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix and remote trust

[zimoun]

Hi Pierre,

On Fri, 13 Dec 2019 at 13:24, Pierre Neidhardt <mail@ambrevar.xyz> 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...


> >  2. publish the store of aneto with "guix publish"
>
> And then install packages from balaitou?  But if Balaitou's "guix" is
> compromised, it does not matter that the substitute server is trusted.

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


> >  3. challenge the store of balaitou against the store of aneto with
> > "guix challenge"
>
> 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


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


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


Well, all this is on theory and principles. :-)

Hope that helps.

Cheers,
simon

Re: Guix and remote trust

[Josh Marshall]

But couldn't a theoretically compromised machine use a VM  to obtain the
valid hashes?

On Fri, Dec 13, 2019, 07:51 zimoun <zimon.toutoune@gmail.com> wrote:

> Hi Pierre,
>
> On Fri, 13 Dec 2019 at 13:24, Pierre Neidhardt <mail@ambrevar.xyz> 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...
>
>
> > >  2. publish the store of aneto with "guix publish"
> >
> > And then install packages from balaitou?  But if Balaitou's "guix" is
> > compromised, it does not matter that the substitute server is trusted.
>
> 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.).
>
>
> > >  3. challenge the store of balaitou against the store of aneto with
> > > "guix challenge"
> >
> > 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
>
>
> > 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.
>
>
> > 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.
> 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.
>
>
> Well, all this is on theory and principles. :-)
>
> Hope that helps.
>
> Cheers,
> simon
>
>

Re: Guix and remote trust

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Pierre,
>
> On Fri, 13 Dec 2019 at 13:24, Pierre Neidhardt <mail@ambrevar.xyz> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix and remote trust

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

Run the VM _inside_ the compromised system?  How can you guarantee that
the VM is not compromised then?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix and remote trust

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

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

Actually I don't think this works either: if the balaitou remote is
compromised, it may very lie about the challenge.

I don't know how `guix challenge' works so I may be wrong here.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix and remote trust

[zimoun]

Hi Pierre,

Thinking a bit of your issue and you have right: you cannot.
I mean, if you cannot trust the Guix daemon on a remote machine,
everything is doomed. Period! :-)

To me, you are asking: how can I verify the validity of a signature
using an untrusted GPG. Well, you cannot. The untrusted GPG can say
whatever it wants then it is game over. Trusting trust attack.

Well, so you need to transport one trusted Guix on the untrusted
machine balaitou.
For example, you create a container with Guix (code and daemon) from
the trusted machine aneto and then you move this container to
balaitou. From the machine balaitou, you start the container mounting
/gnu/store/ and verify the integrity (using the trusted guix). Then
you will know if you can trust or not the /gnu/store.
Something like that... I do not know.


Cheers,
simon