From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jacob Bachmeyer Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 06 Dec 2016 17:46:14 -0600 Message-ID: <58474DC6.4050703@gmail.com> References: <58474630.3040707@gmail.com> Reply-To: jcb62281@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1481068087 4348 195.159.176.226 (6 Dec 2016 23:48:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2016 23:48:07 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 07 00:48:01 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 1cEPSo-0007qC-7U for ged-emacs-devel@m.gmane.org; Wed, 07 Dec 2016 00:47:58 +0100 Original-Received: from localhost ([::1]:35541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEPSq-0003hT-CW for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 18:48:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEPSF-0003hM-0V for emacs-devel@gnu.org; Tue, 06 Dec 2016 18:47:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEPSA-0006NE-0U for emacs-devel@gnu.org; Tue, 06 Dec 2016 18:47:23 -0500 Original-Received: from mail-oi0-f65.google.com ([209.85.218.65]:34986) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cEPS9-0006Mu-Ro for emacs-devel@gnu.org; Tue, 06 Dec 2016 18:47:17 -0500 Original-Received: by mail-oi0-f65.google.com with SMTP id v84so43321272oie.2 for ; Tue, 06 Dec 2016 15:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=2bQO7Jnnwy97dpgUtSR9LDx4IaBwMRSnNWv8Pqi0/m0=; b=lLSaDcptJ8EZJgE0h4KkMdagfAlDm/c3t4GaUr4PkrEtfxZe9zm7egM5NSxGeDVEwW wMy1lerOgIc3rTrrkfyHRIwblEKvWLqobl4bF/9/98MR3xfO7mGWQUCBaJekcgGjDKvR 39s0uTI1XDBs+jwyOrOzD9blRAAx1nWeQMdCCHx3aSEVrewef0hyemWHlpRxURD3fcfb LlXRFSbXz5iDqQV3W4Oq1vegJ0jwZIii4beHuZS/FlhoOO1/oNZ+phT5uCr5Hy79Jb2L 3ChvE9k/BK9tD5S1xm4dNKNk0rY0L/GMtY+bL6/BMl9Cwdfb8WX31A1+ng1UB59lovMm 8Aag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:user-agent :mime-version:to:cc:subject:references:in-reply-to :content-transfer-encoding; bh=2bQO7Jnnwy97dpgUtSR9LDx4IaBwMRSnNWv8Pqi0/m0=; b=BJbbQVfPxKHcsujEMeO6iFDqqN6W/5WPQRg+MdTI1vJlFvdZ19eBUDOg9DIM+Oqs5J hPDA1PDYDPGZUN8Q+58VCIsZvsKrRe0peZAVcbAPNss7nM1Zhyl9ybhW2GE+baFHDho8 ILcmMIcDnmOS14nyILFBMFL9uSH/RVDw15N96NQrAe/2jlIcR87muR9BXo/GkMW15msj Ck3VDxeMZuQtZ/xaLmDd76neZQDMKyqGqI9fv4NiU6JHUAO78zjM11A6svOuoKwfvpjD /o3emzxIl1BhBUd7OoyGzO+p9UmW/AYpfG3q6arNiKqsqkk60xCyGIHsUeesscXLWyyp lstQ== X-Gm-Message-State: AKaTC01qypZqWsjFNB6/t5u5rklv1xwiRu3zV5RGINwuet86hG/rBxyI3iZ1yB56pMmbDQ== X-Received: by 10.157.33.90 with SMTP id l26mr33269470otd.220.1481067976844; Tue, 06 Dec 2016 15:46:16 -0800 (PST) Original-Received: from [192.168.2.42] (adsl-70-133-149-96.dsl.ablntx.sbcglobal.net. [70.133.149.96]) by smtp.gmail.com with ESMTPSA id h53sm8483321ote.32.2016.12.06.15.46.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Dec 2016 15:46:16 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.218.65 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:210098 Archived-At: Daniel Colascione wrote: > 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.) > "A strange game. The only winning move is not to play." The system Emacs dump cannot be modified by a user's account. A per-user dump could be. Currently, this particular persistence option for a (user-level) intruder does not exist; I argue that we should think very carefully before creating it. (No objection to using this for the system Emacs dump, though.) A counter-proposal to signing the dump: upon loading the dump, display a digest or randomart-like image that summarizes the dump. Users who care can then notice if the dump changes when it should not. >> 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 > Some of the comments on that blog are appropriate here. This kind of "not a security problem because " is a position for which Microsoft is infamous. The issue that I see is that a per-user Emacs dump (which of course must be writable by the user) is a place (platform-independent, even!) where an attacker can hide a bit of code to make future access easier, even after the exploit that initially allowed the attacker to get in is fixed. I consider that an attacker who gets in, but leaves traces and is detected, has "won the battle and lost the war". -- Jacob