From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: security of the emacs package system, elpa, melpa and marmalade Date: Fri, 27 Sep 2013 17:04:55 +0200 Message-ID: <877ge29ug8.fsf@wanadoo.es> References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> <52432BE9.1070402@binary-island.eu> <87d2nw1j3b.fsf@uwakimon.sk.tsukuba.ac.jp> <5245939B.9080305@binary-island.eu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1380294326 4757 80.91.229.3 (27 Sep 2013 15:05:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Sep 2013 15:05:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 27 17:05:26 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 1VPZbh-0007Ha-RA for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 17:05:25 +0200 Original-Received: from localhost ([::1]:37023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPZbh-0004Ny-CU for ged-emacs-devel@m.gmane.org; Fri, 27 Sep 2013 11:05:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPZbZ-0004Nl-Nq for emacs-devel@gnu.org; Fri, 27 Sep 2013 11:05:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPZbQ-0004mT-0r for emacs-devel@gnu.org; Fri, 27 Sep 2013 11:05:17 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:59334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPZbP-0004i4-RL for emacs-devel@gnu.org; Fri, 27 Sep 2013 11:05:07 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VPZbO-000711-7E for emacs-devel@gnu.org; Fri, 27 Sep 2013 17:05:06 +0200 Original-Received: from 168.red-83-32-115.dynamicip.rima-tde.net ([83.32.115.168]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Sep 2013 17:05:06 +0200 Original-Received: from ofv by 168.red-83-32-115.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Sep 2013 17:05:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 168.red-83-32-115.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:z4zdCHMBvhg6RmoztqTe7yG7Mho= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:163682 Archived-At: Matthias Dahl writes: [snip] > As a counter example: Plugins distributed through addons.mozilla.org > are checked for security - initial versions as well as updates. I don't think that comparing Emacs to a web browses used by tens of millions is fair. The later is a major attack target/vector for any crook, while Emacs is mostly uninteresting. No matter all the effort the Mozilla guys put on security, it is their web browser the real security threat on your system, not Emacs. > - An Emacs plugin can do whatever it chooses to do with the full > privileges of the current user. But why give a plugin all such power > in the first place? Informing the user beforehand what privileges a > plugin required and thus tightening the belt on a plugin, would make > things more transparent and more secure. Yes, sure. And I think that it can be achieved without too much effort (read: without rewriting whole chunks of Emacs code.) Add support for declaring the capabilities the .el file being read requires: write access to the filesystem, network I/O, running processes, etc. Encode that on a data structure (a plain integer would do) associated to each function on that .el file. Then, when a function is executed its permissions becomes effective and are checked by the primitive functions that implement the sensitive operation. Of course, when function F calls function G the permissions of F are effective over G, on a restrictive way. Also, it could be possible to declare "safe" functions which privileges can override the caller permissions on a permissive way. Those functions would be on the Emacs core, of course. I guess that this schema would require minimal changes to the interpreter, byte compiler and core functions that perform sensitive operations. On exchange, the user would know that such and such packages are not allowed to send his all-important files through the internet, nor delete his entire home directory. [snip]