From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 06 Dec 2016 15:18:32 -0800 Message-ID: References: <58474630.3040707@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481066359 18197 195.159.176.226 (6 Dec 2016 23:19:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2016 23:19:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Jacob Bachmeyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 07 00:19:15 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEP10-00048p-Eq for ged-emacs-devel@m.gmane.org; Wed, 07 Dec 2016 00:19:14 +0100 Original-Received: from localhost ([::1]:35464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEP14-0007FG-Fp for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 18:19:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEP0T-0007Ez-01 for emacs-devel@gnu.org; Tue, 06 Dec 2016 18:18:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEP0R-0004jl-TX for emacs-devel@gnu.org; Tue, 06 Dec 2016 18:18:41 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:41732) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cEP0R-0004je-K5 for emacs-devel@gnu.org; Tue, 06 Dec 2016 18:18:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=YdBM5ltmGO1gXnke+jtQB3QvpgxomDO0nrK4JO1wEvU=; b=XCHik0GbOCrLl4hM3m5Ui+XG6bD4SCUBwCEaVEsylivJ4zTWg3HDDdaEZAUPQPcJBDPvrpPUx3UFyZFT4g+sS8Idn4O0rKHEV9nw1YesYGGSqQvrBra+IC23WSiR3MhS40b3vhqJD9TZDsOAJe1u/N5zFRTkvYGl1KOy+6K/yaInx2ZjnUNIxxfxu3CdPyUZsk84C52GtwoGQk+rQOwQ5kJp7lFlsdxHBuxZCsR73l09ewMumXNDe1rNcMjYlqavCkh0dsGCSefi+GAM+6kVGFFBkIhpi/1XZ1E6bvedx8GmOXW6hSE7IH0EWf6CNG4dBAR6uI2YuPc61qKVwsbtRA==; Original-Received: from [2620:0:1008:100b:e09d:7a70:930f:cf3f] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cEP0Q-0006Ze-QN; Tue, 06 Dec 2016 15:18:38 -0800 In-Reply-To: <58474630.3040707@gmail.com> (Jacob Bachmeyer's message of "Tue, 06 Dec 2016 17:13:52 -0600") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210097 Archived-At: On Tue, Dec 06 2016, Jacob Bachmeyer wrote: >> >> (Or we could just randomize per-user and dump Emacs the first time it >> runs for a particular user? If we do that after loading ~/.emacs, we >> also improve people's startup time. Invalidating and regenerating the >> dump when configuration changes would be a challenge though.) > > That should not be too difficult, if you can track which files were > read when creating the dump and store some fields from the stat(2) > information on those files in the dump. I am using this approach in a > packaging system that I am developing to close a race between > attaching a file to an archive handle and actually writing the > archive, at which time the digest of the file is computed. (I wanted > to avoid reading input files twice.) > > I take a conservative approach and verify that the > st_{ino,dev,size,blocks,{m,c}tim{e,.tv_nsec}} fields are all > unchanged. For my use, writing the archive produces a hard failure if > this check fails; for Emacs, failing that check would indicate "time > to rebuild the fast-load cache". > > > On the other hand, I think that per-user dumps are a bad idea--the > Emacs dump is an inscrutable binary blob Users run lots of inscrutable binary blobs. At least this one is made from free software. ("Sure", you might think, "we can just have the system Emacs *sign* the blob." But an attacker could just read the private key right out of the Emacs binary. You really can't win.) > and therefore a good place > for an intruder to hide persistent nastiness. This could allow an > intruder to add a back door to a user's Emacs in a difficult-to-detect > manner while needing only temporary access to that user's account, > say, from exploiting any program that user runs. I don't think attempting to defend against this sort of attack, at least the way you suggest, is desirable. An attacker who can modify user files like that has already won --- there are all sorts of user-mode "rootkits" that hide themselves very effectively. https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283