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: Wed, 25 Sep 2013 20:31:05 +0200 Message-ID: <52432BE9.1070402@binary-island.eu> References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1380133886 18232 80.91.229.3 (25 Sep 2013 18:31:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Sep 2013 18:31:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 25 20:31:30 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 1VOts1-0005bt-S1 for ged-emacs-devel@m.gmane.org; Wed, 25 Sep 2013 20:31:29 +0200 Original-Received: from localhost ([::1]:54279 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOts1-0002jS-Dz for ged-emacs-devel@m.gmane.org; Wed, 25 Sep 2013 14:31:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOtrm-0002TU-5S for emacs-devel@gnu.org; Wed, 25 Sep 2013 14:31:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOtrf-0000Qy-T1 for emacs-devel@gnu.org; Wed, 25 Sep 2013 14:31:14 -0400 Original-Received: from hemera.binary-island.eu ([97.107.138.233]:46218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOtrf-0000Qq-Ps for emacs-devel@gnu.org; Wed, 25 Sep 2013 14:31:07 -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 58F293C083; Wed, 25 Sep 2013 14:33:13 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: 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:163642 Archived-At: Hello Stefan... > Security problems in Emacs are everywhere, indeed. Actually not quite the statement one wants to read _ever_ about the software one loves to use. ;) The question that is bugging me now: Why is that? Since Emacs, imho, addresses a more technical audience and is maintained by professionals, I wouldn't expect such a thing, actually. Especially since it is not written in such a commong language that everyone learns during their first years in high-school or university which implies a certain level of interest and knowledge in programming if one decides to tackle lisp. Regarding your examples: You are absolutely right, it is a tough problem to solve... especially without sacrificing any freedom that everyone has come to love about Emacs. And it would require more than just one person trying to get this done. Zooming out a bit: A major mode that wants to run external programs could either define them through its permission file which would _not_ be part of its package but some properties on the package server that can only be changed by its staff. Or Emacs could ask the user the first time, if it is okay to execute the following programs with arguments xyz and remember that change. All of those security relevant data should go into a separate file naturally that Emacs protects from access, so a plugin could not tamper with the datastore and gain priviledges that way after a restart. Hooks. If a security context is attached to a function (let's say transitively through its package): function A is running with all permissions function A calls its hook each hook is executed within its own security context (=> narrowing) I'm just throwing my thoughts in the mix at this time. All this would need a lot more thought and work, obviously. But I honestly think this would be a goal worth pursuing since security should never be taken lightly, imho. Nevertheless if there is zero traction from the community such a project would be doomed to fail. And right now, we are the only two in this discussion which could be seen as a lack of interest. :( Don't get me wrong, I'm not complaining or trying to force something. Just trying raise a little awareness and maybe ignite some discussion that potentially leads to a solution that improves overall security. Thanks Stefan by the way for taking the time. Much appreciated. So long, Matthias -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu services: custom software [desktop, mobile, web], server administration