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 18:50:58 -0600 Message-ID: <58475CF2.5080907@gmail.com> References: <58474630.3040707@gmail.com> <58474DC6.4050703@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 1481071985 27253 195.159.176.226 (7 Dec 2016 00:53:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Dec 2016 00:53:05 +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 01:53:00 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 1cEQTi-0005Ya-8C for ged-emacs-devel@m.gmane.org; Wed, 07 Dec 2016 01:52:58 +0100 Original-Received: from localhost ([::1]:35699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEQTj-0003Ee-55 for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 19:52:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEQT8-0003EX-Bm for emacs-devel@gnu.org; Tue, 06 Dec 2016 19:52:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEQT5-0000sO-6n for emacs-devel@gnu.org; Tue, 06 Dec 2016 19:52:22 -0500 Original-Received: from mail-oi0-f66.google.com ([209.85.218.66]:36606) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cEQSo-0000ro-3Q for emacs-devel@gnu.org; Tue, 06 Dec 2016 19:52:19 -0500 Original-Received: by mail-oi0-f66.google.com with SMTP id u15so43652681oie.3 for ; Tue, 06 Dec 2016 16:52:01 -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=R6zM2+fXpsvJQaMg8VYBJuDXJVqElsSMLl+HihcjL+Q=; b=fzvAEnFS6DVklknTV91JQ6u/hmJfpDeAVksgyznfaaBt9JTiB/wDZ77/vHkKEj0cc6 LoDpWY0YJ3Su123I8u6kF7d6yNsRk+5PsxrRPRbEUIm0gH/z1X6AgQAoIBCnzbHimLRS XLtsNVWrDy4u3nVUqMr1ITKs4Xx67xqoarg4IBBnsl4CO63HlIX6wqeHoan+mNln3lXX mBZrZ77vI8rlf4lczoGR7YSzkadK08qriPDKa/zki3xjrOevUcXHRPPoTJF+lqhf6Mnt /oZ9L9h2CEngQR13Jo3m/R0JiD6FBL9AHWw5v+VRUJgi/oyelOVbeTF8LAG89xoneLH8 jezw== 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=R6zM2+fXpsvJQaMg8VYBJuDXJVqElsSMLl+HihcjL+Q=; b=LCXrk8t5I8B/HbDrz0s0AiAVu790GZ+ccrHzCTUozUS+/Blmo/d44GBOlub307UxsS XNgozO65/phItSM7Q672SCtdsmNnwevYVZKEfEcNa7CydtUqFubJ+yQrTyw05W6Vrs27 +So52DFPiLPigU0uZUCiDMd0dTktcyAwdjCdi+5MtPi3xKkw6b/dazCaxYrwGCJ3n1OH DC3m2Vl0xrqcyOjT3i+0js0I98pKi0cP7UiXnRM1kcRpBdvm5go+zarQDDoCFjhBZ/bs 908UIBY3MvCCz9CMbe6tq+kdJjsrjWFEAQ6lBx2MoHlVCQiKJL4NadzZODBcnfiDrukQ jixg== X-Gm-Message-State: AKaTC00m9oPu3y7oCrizX+KkSlecck76LeYWybjd0RhdWVKgU32RwrYbaUcUqCRkkPkDpw== X-Received: by 10.157.19.23 with SMTP id f23mr34216464ote.116.1481071861019; Tue, 06 Dec 2016 16:51:01 -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 t78sm8532928oih.19.2016.12.06.16.50.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Dec 2016 16:51:00 -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.66 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:210100 Archived-At: Daniel Colascione wrote: > 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 multi-user secure environment may forbid binaries in $HOME entirely and mount /home noexec. >> 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. > It is sad how many people just do not care. Then they complain when told that their email account is sending spam. Back to the topic, how would this annoy users? Put it in the splash screen with other details like the Emacs version that the willfully ignorant will ignore. "This is GNU Emacs () of on using image " >>>> 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. > Modifying .profile is riskier for the attacker than modifying a binary dump. A system backup facility, for example, will notice that the user's .profile has changed and will probably store the diff. A security policy may have a system daemon scanning user .profiles for references to LD_PRELOAD. > 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. > I did not say that we absolutely should not have per-user dumps, only that we should consider the risks that they introduce. At the least, there should be an option to not use per-user dumps. This would be very little of a problem, since the portable dump mechanism will allow for dumps to be incrementally built. This will enable a user dump to be built/updated by loading the system dump, processing .emacs (or some special user loadup file if the user does not want .emacs in the dump) and saving a new dump file. Or for user dumps to be unused, and we stay right where we are now on those systems, but without depending on the internals of libc. >> 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. > This comes back to an attacker "winning the battle and losing the war"--if you do not know your account has been compromised, then you do not know that you should be restoring from backup--and the attacker "wins the war". Non-persistent "smash-and-grab" attacks have an important advantage for the attacker in this sense. That integrity in Free environments is currently a mess is no reason to charge ahead without considering what effects our efforts will have on the situation. I had meant to suggest a solution to the problem of invalidating a user dump/fast-load cache; I have been surprised that the discussion has been more about an offhand remark expressing uncertainty about the wisdom of per-user dump files. To be clear: I am in favor of supporting per-user dumps, but vehemently opposed to forcing their use. If nothing else { alias emacs='emacs --load-dump=~/.emacs.pdmp'; } will provide support for per-user dumps whether or not Emacs itself checks for one. -- Jacob