From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: security of the emacs package system, elpa, melpa and marmalade Date: Sat, 28 Sep 2013 02:31:05 +0900 Message-ID: <8738oq189y.fsf@uwakimon.sk.tsukuba.ac.jp> References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> <52432BE9.1070402@binary-island.eu> <87d2nw1j3b.fsf@uwakimon.sk.tsukuba.ac.jp> <5243F828.6060901@binary-island.eu> <87a9iy2106.fsf@uwakimon.sk.tsukuba.ac.jp> <524593A0.7020502@binary-island.eu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1380303089 21482 80.91.229.3 (27 Sep 2013 17:31:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Sep 2013 17:31:29 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Matthias Dahl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 27 19:31:31 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 1VPbt5-00077l-1y for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 19:31:31 +0200 Original-Received: from localhost ([::1]:37803 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPbt4-000541-MP for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 13:31:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPbsv-00052z-Cs for emacs-devel@gnu.org; Fri, 27 Sep 2013 13:31:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPbsn-0000Qh-Tm for emacs-devel@gnu.org; Fri, 27 Sep 2013 13:31:21 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:44347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPbsn-0000Po-Cg for emacs-devel@gnu.org; Fri, 27 Sep 2013 13:31:13 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 199059709EA; Sat, 28 Sep 2013 02:31:06 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D34B01A27EF; Sat, 28 Sep 2013 02:31:05 +0900 (JST) In-Reply-To: <524593A0.7020502@binary-island.eu> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:163686 Archived-At: Matthias Dahl writes: > > Well, sure. A concrete block is inherently more secure against > > an earthquake than a building. That doesn't mean we should > > replace the latter with the former. > > Stephen, I'm not advocating we should all drive around in an > armored car or never ever connect our computers with the evil > internet or whatever. It's an exaggeration. See below. > All I am saying is: It would be very helpful if we could give the > user a few tools to handle, grasp and maybe harden certain security > aspects. And in this concrete discussion: It is all about plugins > who, once they are installed through whatever means, can also do > whatever they choose. Sure. *Preventing* that is going require doing something that is probably impossible for any program that isn't an operating system in control of the machine. > You wouldn't work as root on your system, would you? I do every day, to run emerge --update. ;-) > And why should a plugin get full rights if just needs a few infos > from the local buffer? It shouldn't. But that question is not interesting and the answer isn't controversial. The interesting question is, "why should a plugin be denied the rights it needs when those go beyond reading the buffer it was invoked from?" > But the reality is, we have to use software that others created. And the > open source/free software world is full of great minds and talents that > create astounding pieces of software. And those people working pouring > the time and life into those projects, usually would never place > any malicious code into their creations. It is through hacks or other > circumstances that such things happen. The world is not inherently > evil. True. The world is not. In fact, most of the bad guys aren't evil, just willing to bend the rules a bit to get their way. Still, cracked is cracked, and it only takes once, no matter what the ratio of great|talented|astounding is to "warped". And that's why the issue here is that the answer to the "interesting question" is the same one that a mother gives to a 5-year-old: "just because". The way to get the necessary permission in general is to ask the user each time the program wants access. > I did not know that the Python devs worked on a sandbox, honestly. They didn't just work on it; they had one (the restricted execution option) and then they stopped distributing it because it didn't keep its promises. There's been work on a better one, but IIRC it hasn't been PEP'ed yet. And nobody except the author (who is very good, I admit) has really tried to "break" it or use it in production. > But the problem here is a bit more "relaxed", imho. We are not talking about > hardening / sandboxing a language in general but only a very concrete > functionality in a specific program (which, granted, is very tightly > intervened with the language it is written in). No, it's *not* a concrete functionality. The concrete functionality is "Shall the plugin be installed?" The answer to that is easy to implement. But if you're talking about preventing an untrusted plugin from doing "evil" things, you need to accompany every call to a sensitive function with some way to determine whether the function should be executed or not. That is a sandbox, but you're welcome to call it by a different name if you like. > [Refusing to install untrusted code] may reduce the risk but is > this really a solution? I believe there is no solution. Security as we understand it today is about preventing some entities from accessing the functionality of certain other entities. The more security, the less functionality can be accessed. You can't get both to 100%. > Say you use only the great jedi.el for your Python development. I > am sure that its author Takafumi Arakaki would never put anything > harmful in it... but I can imagine several scenarios how something > harmful could end up in it nevertheless without him noticing it for > a while. Sure. But the chances are pretty good that I would. Anyway, the definition of "absolutely need" is "I'm willing to bet that I or some other user would catch it even if the author doesn't." There's another answer based on the details of your example. I avoid doing development on exposed hosts. In one sense that's unfair, but in another it goes to the heart of the matter.