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 16:04:36 -0800 Message-ID: References: <58474630.3040707@gmail.com> <58474DC6.4050703@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481069260 31296 195.159.176.226 (7 Dec 2016 00:07:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Dec 2016 00:07:40 +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 01:07:36 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 1cEPln-0007JZ-2J for ged-emacs-devel@m.gmane.org; Wed, 07 Dec 2016 01:07:35 +0100 Original-Received: from localhost ([::1]:35611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEPlr-0007XU-4r for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 19:07:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEPlA-0007Fj-Qg for emacs-devel@gnu.org; Tue, 06 Dec 2016 19:06:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEPl7-0005Kh-Jz for emacs-devel@gnu.org; Tue, 06 Dec 2016 19:06:56 -0500 Original-Received: from dancol.org ([96.126.100.184]:58228) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cEPl7-0005KI-A7 for emacs-devel@gnu.org; Tue, 06 Dec 2016 19:06:53 -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=sVncqelcvFkE8VjZRhxTHuMYdveRmXUZvdhXiIOBUV4=; b=Ps6nVjzljQNZF1DimlEHiyCOH+8KUmvXri9BX6LmxRTeDD2YeDN7/1hSScUS7oAGdE9AhWjDXLiX+YDY0pWkoSnR1BHyf8soXZFDdr8ATRbVVJ/hL3AdNHPUvmcv3RNGlXgaZF5rJDW80Vo8mFXo7B7+Vt+oFPK+r7DNPXe9cw5wNBcNkPAMZ+H8IbDLaFvVx4ESLAHwnXEc96qLlpOzm94oMTT1GmNnq3CDYMNcJKdbWFxHzfZ0Kern9T2Xh0dA9iU5yradHYExd4vbPtyMKR81QLKAGz35J2+xoR+QtlmcyslufR+4KhlBj3o9NwSCN5ZUnfLSD1dDsoDGOOAs6w==; 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 1cEPiz-0006z1-UM; Tue, 06 Dec 2016 16:04:42 -0800 In-Reply-To: <58474DC6.4050703@gmail.com> (Jacob Bachmeyer's message of "Tue, 06 Dec 2016 17:46:14 -0600") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 96.126.100.184 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:210099 Archived-At: On Tue, Dec 06 2016, Jacob Bachmeyer wrote: > 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.) And you don't have any binaries under $HOME? No elc files? No .pyc files? Really? Are you sure that you can read a pyc file and detect exploit code? > 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. That'll annoy users, and I've never seen a real human being pay attention to those SSH key fingerprint ASCII art things, much less some weird art thing that Emacs might display on startup. >>> 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. That the author of that post works for Microsoft is irrelevant. "Security" is a meaningless word. You need to be secure *against* something. You need a threat model. Your threat model is an attacker who already has the ability to overwrite files under $HOME. Such an attacker can do anything anyway (e.g., LD_PRELOAD something in ~/.profile that presents whatever secure fantasy the attacker wants to present), so your proposed security measure doesn't actually help --- and it has costs. Sorry: I don't think that forgoing user dumps on security grounds makes any sense. There might be plenty of other reasons not to implement the feature, but security isn't one of them. That's not "an excuse" --- as if implementing any random feature somebody proposes in the name of "security" is some moral imperative, we need to be excused from our duty to perform it --- it's reason. > 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. System compromises are never "fixed": there are too many places for attackers to hide code. If your account has been compromised, you lose. Restore from backup.