#47614 [security] Chunked store references in .zo files in Racket 8

Message #22 received at 47614@debbugs.gnu.org (full text, mbox, reply):

Received: (at 47614) by debbugs.gnu.org; 13 Apr 2021 21:29:03 +0000
From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 17:29:03 2021
Received: from localhost ([127.0.0.1]:32788 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1lWQak-00045Y-QA
	for submit@debbugs.gnu.org; Tue, 13 Apr 2021 17:29:03 -0400
Received: from world.peace.net ([64.112.178.59]:35854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@netris.org>) id 1lWQai-000451-MQ
 for 47614@debbugs.gnu.org; Tue, 13 Apr 2021 17:29:01 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@netris.org>)
 id 1lWQac-0001MN-09; Tue, 13 Apr 2021 17:28:54 -0400
From: Mark H Weaver <mhw@netris.org>
To: Léo Le Bouter <lle-bout@zaclys.net>, 47614@debbugs.gnu.org
Subject: Re: bug#47614: [security] Chunked store references in .zo files in
 Racket 8
In-Reply-To: <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@zaclys.net>
References: <87k0pf7jti.fsf@netris.org>
 <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@zaclys.net>
 <87tuojqf0r.fsf@netris.org>
 <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@zaclys.net>
Date: Tue, 13 Apr 2021 17:27:11 -0400
Message-ID: <87a6q1swmt.fsf@netris.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47614
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Léo,

Léo Le Bouter <lle-bout@zaclys.net> writes:

> On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote:
>> 
>> Léo Le Bouter <lle-bout@zaclys.net> writes:
>> 
>> > I think that probably replacing arbitrary paths in built binaries
>> > is a risky and maybe unreliable engineering choice and that
>> > mechanisms inside kernels should be preferred to give processes a
>> > different view of the file system (retaining the path but changing
>> > the contents of the folder).
>> 
>> I've had thoughts along these lines myself, but I don't think it can
>> work properly.  The fundamental problem is that in general, each
>> process includes shared objects from many different Guix packages.
>> There would need to be a mechanism to determine, when looking up a
>> file, which Guix package that file lookup was originating from (or
>> whether it was coming from a file name provided by the user), in
>> order to determine which "view of the file system" to use for
>> purposes of that lookup.  There's no way to determine this reliably.
>
> Is it really that big a deal if it's impossible to access the ungrafted
> /gnu/store item? 

It's a fair question, and reasonable people may disagree, but I would
personally find it quite troubling to not be able to confidently and
straightforwardly examine files in /gnu/store without wondering if my
tools were showing me something else.

Anyway, this would be a very radical change in Guix, and I think this
bug report is not the best place to discuss it.  If you'd like to persue
this idea further, I suggest starting a thread on 'guix-devel'.

>> > OTOH, what would be wrong with replacing hashes directly without
>> > expecting them to be next to anything else?
>> 
>> Personally, I would find that limitation acceptable, and that's
>> fairly close to what our grafter originally did (although my fast
>> grafting code always assumed that a "-" would follow the hash).
>> However, we've since become accustomed to being able to have
>> replacements with different version numbers.  That's a nice feature.
>
> Version numbers, agree, I didnt realize that replacing the program name
> and version was also required there. However I am thinking we could
> fake (or alias, with a symlink) the version in the store item name on
> purpose so that it remains the same while pointing to something with a
> newer version, it would actually be better that way because we wouldnt
> have to think about retaining identical version string length during
> grafts.

This idea is the subject of <https://bugs.gnu.org/43984>, and it's
certainly doable.  The main disadvantage I see is that file system
lookups in grafted store items would become less efficient, because more
symbolic links would need to be followed.  Anyway, if you'd like to
persue this idea further, let's discuss it in that other bug report.

>> Anyway, I doubt that imposing such a limitation would adequately
>> solve the problem here of chunked references in Racket 8, because I
>> suspect that Racket 8 could split store references at arbitrary
>> points in the string.  I doubt that we can safely assume that the
>> hash component of store references will be stored contiguously in
>> *.zo files.
>
> Indeed, is the format for the string references in .zo files documented
> anywhere? Is there hope you think we can recognize and automatically
> rewrite these strings?

According to Philip McGrath, "The .zo format is intentionally
undocumented and subject to breaking change, including from different
compilation options."  See <https://bugs.gnu.org/47614#19>.

     Thanks,
       Mark

Send a report that this bug log contains spam.