Can unprivileged users corrupt the store with bad tarballs?

Can unprivileged users corrupt the store with bad tarballs?

[Mark H Weaver]

I was thinking about the security implications of giving out shell
access to one of my systems running Guix.

When I ask guix-daemon to build package 'foo', it will use as an input
the source for package 'foo', usually a tarball.  If the tarball is
already in the store, it won't download it again, because it is
effectively cached in the store.

It is possible for another user on the same system to corrupt the cache,
but manually adding a bad tarball for 'foo' to the store, in such a way
that it would be used to build 'foo' when I ask for it?

      Mark

Re: Can unprivileged users corrupt the store with bad tarballs?

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> I was thinking about the security implications of giving out shell
> access to one of my systems running Guix.
>
> When I ask guix-daemon to build package 'foo', it will use as an input
> the source for package 'foo', usually a tarball.  If the tarball is
> already in the store, it won't download it again, because it is
> effectively cached in the store.
>
> It is possible for another user on the same system to corrupt the cache,
> but manually adding a bad tarball for 'foo' to the store, in such a way
> that it would be used to build 'foo' when I ask for it?

No.

Tarballs are fixed-output derivations, so the hash of the tarball is
known in advance.  Thus, when building a package, you’re sure to use the
tarball whose hash is in the recipe.

Ludo’.

Re: Can unprivileged users corrupt the store with bad tarballs?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I was thinking about the security implications of giving out shell
>> access to one of my systems running Guix.
>>
>> When I ask guix-daemon to build package 'foo', it will use as an input
>> the source for package 'foo', usually a tarball.  If the tarball is
>> already in the store, it won't download it again, because it is
>> effectively cached in the store.
>>
>> It is possible for another user on the same system to corrupt the cache,
>> but manually adding a bad tarball for 'foo' to the store, in such a way
>> that it would be used to build 'foo' when I ask for it?
>
> No.
>
> Tarballs are fixed-output derivations, so the hash of the tarball is
> known in advance.  Thus, when building a package, you’re sure to use the
> tarball whose hash is in the recipe.

What about things that aren't fixed-output derivations?  Are the results
of 'origin' forms with included patches or snippets "fixed-output"?

Could an unprivileged user add one of these to the store that wasn't
authentic?

     Mark

Re: Can unprivileged users corrupt the store with bad tarballs?

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> I was thinking about the security implications of giving out shell
>>> access to one of my systems running Guix.
>>>
>>> When I ask guix-daemon to build package 'foo', it will use as an input
>>> the source for package 'foo', usually a tarball.  If the tarball is
>>> already in the store, it won't download it again, because it is
>>> effectively cached in the store.
>>>
>>> It is possible for another user on the same system to corrupt the cache,
>>> but manually adding a bad tarball for 'foo' to the store, in such a way
>>> that it would be used to build 'foo' when I ask for it?
>>
>> No.
>>
>> Tarballs are fixed-output derivations, so the hash of the tarball is
>> known in advance.  Thus, when building a package, you’re sure to use the
>> tarball whose hash is in the recipe.
>
> What about things that aren't fixed-output derivations?  Are the results
> of 'origin' forms with included patches or snippets "fixed-output"?

No, these are normal derivations.

> Could an unprivileged user add one of these to the store that wasn't
> authentic?

No, because unprivileged users have to make RPCs to guix-daemon to
populate the store (the daemon is a “security kernel”.)  The daemon
ensures that .drv files added to the store are valid, that is, that the
output directories that they claim to build have a valid hash.

Then, whether or not substitutes or offloading are used (and which
substitute servers or build machines are used) is configured by root.
Thus, an unprivileged user cannot maliciously inject derivation outputs
in the store other than those built/substituted in a way approved by the
system administrator.

Eelco’s <http://nixos.org/~eelco/pubs/secsharing-ase2005-final.pdf>
discusses this in more detail (Nix and Guix use what the paper refers to
as the “extensional model,” although fixed-output derivations look more
like the “intensional model”.)  A recommended read!  :-)

Ludo’.