From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: package security auditing and isolation Date: Thu, 06 Apr 2017 11:45:58 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87d1cp1qvd.fsf@lifelogs.com> References: <87h9211v1c.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1491493644 23757 195.159.176.226 (6 Apr 2017 15:47:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Apr 2017 15:47:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 06 17:47:21 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cw9cp-0004Wp-4Q for ged-emacs-devel@m.gmane.org; Thu, 06 Apr 2017 17:47:07 +0200 Original-Received: from localhost ([::1]:46577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cw9cu-0000rr-T1 for ged-emacs-devel@m.gmane.org; Thu, 06 Apr 2017 11:47:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cw9c5-0000q6-0f for emacs-devel@gnu.org; Thu, 06 Apr 2017 11:46:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cw9c1-00056w-2x for emacs-devel@gnu.org; Thu, 06 Apr 2017 11:46:21 -0400 Original-Received: from [195.159.176.226] (port=59143 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cw9c0-00056k-ST for emacs-devel@gnu.org; Thu, 06 Apr 2017 11:46:17 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cw9bo-00079p-Vz for emacs-devel@gnu.org; Thu, 06 Apr 2017 17:46:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 51 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:Lnq+2Zj6MLQ5wfDDgf643Hl5f4o= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:213716 Archived-At: On Thu, 06 Apr 2017 10:48:20 -0400 Stefan Monnier wrote: >> I propose two specific pieces of functionality, which I think are >> essential to this task: >> >> 1) tools for analyzing the source code and finding the function calls >> that can be dangerous. This includes eval, calling the shell, etc. >> >> I don't know how feasible this is, but IMHO it would be valuable. At the >> very least it could make code reviews easier by focusing on the >> potentially problematic sections. I think Emacs' core is the right place >> to add such code, not modules or add-on packages. SM> Are you thinking of this to protect against accidental problems, or to SM> protect against a malicious attacker? To help code reviews find malicious changes. SM> It seems like it would be completely ineffective against a malicious SM> attacker (especially if such an tool auditing is "standardized"), but SM> I can't imagine it being very effective for the accidental case either. Can you elaborate on what could make it effective? Or, alternatively, why the idea is fundamentally flawed and if there are better ones? The goal I stated is to "audit and isolate packages from modifying the user's system... because any ELPA repository, its sources, and its signing process can be compromised for at least a short time." If my suggestion is ineffective, can you make suggestions to improve the situation? Another idea: add some UI in package.el to see what code changes are getting installed with a package install update. That would be a quick way to give users some visibility. It's not a solution, and it's poor UI, but it's a start. >> 2) establishing isolation levels in the C core. Simply put, not all >> packages need to be able to run shell commands, delete or modify files, >> and so on. When the user installs or updates a package, if the needed >> access levels change, that should be noted and acknowledged. SM> That could be done, but it's a major restructuring, which will probably SM> require major changes to be able to isolate packages from each other. If you, with your deep knowledge of the C core, could start a *top-level* list of the necessary changes, that would be really helpful. We don't have to do it all today, or this year. But we have to start somewhere. Ted