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: security of the emacs package system, elpa, melpa and marmalade Date: Mon, 23 Sep 2013 09:30:35 +0200 Message-ID: <523FEE1B.9020408@binary-island.eu> 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 1379921455 25571 80.91.229.3 (23 Sep 2013 07:30:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Sep 2013 07:30:55 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 23 09:30:55 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 1VO0be-0001Sh-92 for ged-emacs-devel@m.gmane.org; Mon, 23 Sep 2013 09:30:54 +0200 Original-Received: from localhost ([::1]:37991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VO0bd-0003WH-Mz for ged-emacs-devel@m.gmane.org; Mon, 23 Sep 2013 03:30:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VO0bV-0003W7-EO for emacs-devel@gnu.org; Mon, 23 Sep 2013 03:30:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VO0bP-0006YE-Ao for emacs-devel@gnu.org; Mon, 23 Sep 2013 03:30:45 -0400 Original-Received: from hemera.binary-island.eu ([97.107.138.233]:39479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VO0bP-0006Xw-5B for emacs-devel@gnu.org; Mon, 23 Sep 2013 03:30:39 -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 698083C083 for ; Mon, 23 Sep 2013 03:32:40 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130920 Thunderbird/17.0.9 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:163568 Archived-At: Hello @all, I know there has been a thread about (more or less) this topic sometime last year, iirc. But I was unable to find something current, so I hope it is okay to raise a few questions and ideas about this subject. As it stands, most Emacs users I guess install quite a few packages from various sources (git repo, elpa, melpa, ...) to mold Emacs to their very specific needs and workflow. The same naturally goes for me. Right now, the only way to make sure there is no malicious code hidden in those packages, is to check each one manually during the initial installation as well as for each update... which can be a very time intensive task and not every person using Emacs is a Elisp guru and can really spot each malicious code fragment. Especially since more and more newer projects recommend installing their package through the package management system (especially MELPA) which makes it even more easy to install something without checking it first. Signed packages on the package server (e.g. ELPA) make sense, if said process is done externally and a security check is performed on the package in question before signing. For MELPA this is an even harder problem to solve, since it is fully automated and thus even signing the package is out of the question since it would not add much of a value. Nevertheless, I think this is a serious problem and a security incident waiting to happen... it is just a matter of time, imho. The best solution imho would be that each package on a package server, no matter which one, is reviewed before being available either through a dedicated staff of volunteers or through a more open process that makes use of the user base somehow (which could be very difficult in terms of trustworthiness). Unfortunately, I see this as something that needs annual financial funding and hard for the Emacs community to achieve. I might be wrong - and I'd like to be, honestly. So, I'd like to propose the following as at least some measure of protection and a first step in making the package system more secure: A package gets a security context which details its very own permissions just like e.g. an Android app. That context is permanent, meaning that if a user action enters package 1 with a narrow permission set which in turn utilizes some functions of a package 2 (which has a rather wide permission set), only the original narrow permission set will be applied and available. This makes the implementation easier and the system more robust against possible workaround/exploits, imho. There are a lot of packages that don't need access to the filesystem, network and other security sensitive areas. If a package got hacked that did not have those permissions in the first place, Emacs could detect a violation, inform the user and end the execution. Naturally, this also implies that the defined permissions should only be alterable on the package server through an authoritative person and not by the package itself. Also, if permissions changed, the user would be informed by Emacs and ask for permission. This would need a lot more detailing like what kind of permissions should be defined (granularity, ...) and how. I'm just throwing my thoughts into the community hive mind, very much hoping not to get crushed fiercely. :) Basically, all I want to achieve with this mail is to get a discussion going about this topic which hopefully could lead to a more secure and even better Emacs package system. Sorry for the wall of text... and thanks for listening, um, reading. :) -- Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu services: custom software [desktop, mobile, web], server administration