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

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

Received: (at 47614) by debbugs.gnu.org; 6 Apr 2021 21:29:43 +0000
From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 06 17:29:43 2021
Received: from localhost ([127.0.0.1]:41938 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1lTtGZ-0007Kc-6H
	for submit@debbugs.gnu.org; Tue, 06 Apr 2021 17:29:43 -0400
Received: from world.peace.net ([64.112.178.59]:46582)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@netris.org>) id 1lTtGX-0007KO-9o
 for 47614@debbugs.gnu.org; Tue, 06 Apr 2021 17:29:41 -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 1lTtGQ-00078F-KH; Tue, 06 Apr 2021 17:29:34 -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: <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@zaclys.net>
References: <87k0pf7jti.fsf@netris.org>
 <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@zaclys.net>
Date: Tue, 06 Apr 2021 17:27:53 -0400
Message-ID: <87tuojqf0r.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:

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

For example, when Emacs stats a file, there's no way to automatically
determine which view of the file system to use for that file lookup.  If
the file being stat'd is a file that the user asked to look at, it
should use the user's view of the file system.  If Emacs is trying to
load one of its own dependent libraries, it should see the file system
view associated with the dependencies of Emacs.  If some code in
GnuTLS's shared library (loaded by Emacs) performs a file lookup, it
should see the GnuTLS file system view.  See the problem?

I've come to think that the Guix approach is the most "correct"
approach, given the APIs that our existing body of software was written
for.  (If we rewrote our software from scratch with different APIs, we
would have more options here, but that would be crazy :)

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

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.

What do you think?

      Thanks,
        Mark

Send a report that this bug log contains spam.