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: Thu, 26 Sep 2013 10:12:56 +0900 Message-ID: <87d2nw1j3b.fsf@uwakimon.sk.tsukuba.ac.jp> References: <523FEE1B.9020408@binary-island.eu> <52429ABD.6090603@binary-island.eu> <52432BE9.1070402@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 1380158001 4925 80.91.229.3 (26 Sep 2013 01:13:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Sep 2013 01:13:21 +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 Thu Sep 26 03:13:24 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 1VP08x-0003De-DX for ged-emacs-devel@m.gmane.org; Thu, 26 Sep 2013 03:13:23 +0200 Original-Received: from localhost ([::1]:55652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP08w-0007bH-GG for ged-emacs-devel@m.gmane.org; Wed, 25 Sep 2013 21:13:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP08m-0007TA-D5 for emacs-devel@gnu.org; Wed, 25 Sep 2013 21:13:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VP08f-0000Ds-2H for emacs-devel@gnu.org; Wed, 25 Sep 2013 21:13:12 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:59578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VP08e-0000DR-Gc for emacs-devel@gnu.org; Wed, 25 Sep 2013 21:13:05 -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 F21179700A7; Thu, 26 Sep 2013 10:12:56 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A980F1A27EF; Thu, 26 Sep 2013 10:12:56 +0900 (JST) In-Reply-To: <52432BE9.1070402@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:163647 Archived-At: Matthias Dahl writes: > 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. Then your model of security is inadequate. Software is *inherently* insecure. Any regular behavior provides an attack surface; large amounts of regular behavior provides a large attack surface. A single breach of the attack surface and you lose. Interfaces between software systems are prolific sources of weak points. Emacs provides a huge attack surface on the individual user *because* it is so capable, and provides interfaces to so many other software systems. That's all there is to it. The fact that Emacs is mostly implemented in Lisp is also a security feature, since it wraps, rather than calls directly, the system functions. This means that although such functions are available (which is an attack vector), serious security breaches such as exploiting a buffer overflow are hard to engineer, and the operating system is likely to be able to protect itself from attacks via Lisp. By the same token, as long as individual users have little power (for example, not being able to bind to privileged ports), they're generally not attractive targets for such attacks. If they are attacked (eg, to get a privilege escalation started), the attacker will eschew use of Emacs and head straight for the C compiler. That, combined with the relative security of Lisp itself, means that the incentive for Emacs developers to put in the necessary effort for a serious security audit and a complete redesign of the Lisp implementation is rather low. > 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) *pong* Function on function-hook doesn't have permission to frob. Allow frob? (0 = no; 1 = just this time; 2 = always; -1 = never) _ But this is really self-defeating. Since in general hooks should be empty by default, what you're saying is that a function that the user has probably explicitly specified and may have written herself should run with less privilege than functions that the user is only vaguely aware of. For example, I don't know who's broken, but every time my "smart" phone upgrades, I have to re-login to my employer's wireless network. And every time, I'm told that the certificate can't be tracked to a trusted root. Of course the phone software is very little help in figuring out what's wrong; it just shows the certificates. I know how to trace the transitive trust, but even so, why should I trust a self-signed root claiming to be the Japanese Ministry of Education, Science, and Technology's IT department? These guys don't have sufficient clue to get a path to a universally trusted root! I also am aware that sub-authorities have gone rogue or been hacked in the past. But ... I enable. Wouldn't you? Definitely my colleagues have no clue. They don't even think about it any more, so many servers present keys for a parent domain or sister domain. Even the CS Department (the initial entry point of the first large-scale virus infection at my university after the virus checker was installed on the mail gateway). Most of these guys are theorists (including in crypto where you'd think they'd be aware -- but no, they're not) and have zero sysadmin experience (and probably haven't read The Cuckoo's Egg). > 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. I'm sure the leadership is aware. But the basic answer is the same as in any security context: avoid exposing regular behavior to potential enemies, and establish a community watch on community resources.