From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Matthias Dahl Newsgroups: gmane.emacs.devel Subject: Re: security of the emacs package system, elpa, melpa and marmalade Date: Thu, 26 Sep 2013 11:02:32 +0200 Message-ID: <5243F828.6060901@binary-island.eu> References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> <52432BE9.1070402@binary-island.eu> <87d2nw1j3b.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1380186174 12326 80.91.229.3 (26 Sep 2013 09:02:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Sep 2013 09:02:54 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 26 11:02:54 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VP7TJ-0008M8-Ne for ged-emacs-devel@m.gmane.org; Thu, 26 Sep 2013 11:02:53 +0200 Original-Received: from localhost ([::1]:56886 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP7TJ-0007JF-1F for ged-emacs-devel@m.gmane.org; Thu, 26 Sep 2013 05:02:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP7T9-0007AH-Fb for emacs-devel@gnu.org; Thu, 26 Sep 2013 05:02:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VP7T1-0006BT-JP for emacs-devel@gnu.org; Thu, 26 Sep 2013 05:02:43 -0400 Original-Received: from hemera.binary-island.eu ([97.107.138.233]:48013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP7T1-0006BD-EQ for emacs-devel@gnu.org; Thu, 26 Sep 2013 05:02:35 -0400 Original-Received: from [10.0.0.20] (95-88-238-193-dynip.superkabel.de [95.88.238.193]) by hemera.binary-island.eu (Postfix) with ESMTPSA id 349963C083; Thu, 26 Sep 2013 05:04:40 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <87d2nw1j3b.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 97.107.138.233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163652 Archived-At: Hello Stephen... > Then your model of security is inadequate. Software is *inherently* > insecure. Agreed. But if someone says there are security leaks all over the place, that is a different story. This implies those are tolerated for various reasons. But they do exist and should be fixed, nevertheless. I would _never_ consider a software secure. But if holes exist that are known and those are not fixed, that is a different story. This does also imply that code slips in that lacks in quality... knowingly. > Emacs provides a huge attack surface on the individual user *because* > it is so capable, and provides interfaces to so many other software > systems. That's all there is to it. Agreed. But this doesn't imply that the user should be powerless against each and every plugin he installs. One can assume that the Emacs code base does not contain any malicious code and is thus "secure" at least in this regard. Naturally there are holes - known and unknown. The key, imho, is to empower the user to have more control over plugins he needs to install. This adds a line of defense that can be built upon. Right now there is absolutely nothing stopping a hacked plugin to do just about anything until the community or the user somehow notices this. > If they are attacked (eg, to get a privilege escalation started), the attacker > will eschew use of Emacs and head straight for the C compiler. Emacs can "easily" be used through a malicious plugin to tamper with the user environment and thus gain all kinds of access and data. It does not need to really make any use of a security hole / leak. > That, > combined with the relative security of Lisp itself, means that the > incentive for Emacs developers to put in the necessary effort for a > serious security audit and a complete redesign of the Lisp > implementation is rather low. That is only half of the story, though. My concern mainly lies with the "plugin" system. Putting some kind of defense there. And yes, in the end this would also possibly mean to harden Emacs here and there to protect this defense system from being tampered with. Things are more intervened than your point of view suggests. > But this is really self-defeating. Since in general hooks should be > empty by default, what you're saying is that a function that the user > has probably explicitly specified and may have written herself should > run with less privilege than functions that the user is only vaguely > aware of. Only thoughts. I was only thinking aloud. :) Again, all of this would need a lot more detailing and testing, obviously. But in general, I would consider user code in the same category as core code, thus full privileges. Now if a function with less privileges called a hook that contains a function with required higher privileges, that would naturally be a very valid use-case that would need further investigation for a suitable solution. > But ... I enable. Wouldn't you? But at least you get a warning. You get information. You can make an informed decision at that time. You do know who you are dealing with, you can somehow at least rudimentarily assess the risks for this very specific case. With Emacs, you can either review each and every change for each and every plugin you have installed - or you are completely on your own. There are no warnings. No checks. Nothing. To expand on your good example: This would be like you had to check the certs all by yourself beforehand by logging in, tracing and validating everything. If you did not do so, well, your choice... and there would be no warning or checks. Nothing. And not everybody uses self-signed certs, by the way. ;) Even though the cert system is broken in several aspects, it still provides some from of valuable clue whether a site (in the most general meaning of the term) is most likely "trustworthy" or not. > I'm sure the leadership is aware. But the basic answer is the same as > in any security context: avoid exposing regular behavior to potential > enemies, and establish a community watch on community resources. And what would you suggest in terms of ELPA / Marmalade and MELPA and the package system in general based on this...? By the way, thanks for your input. It is very much appreciated. So long, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu services: custom software [desktop, mobile, web], server administration