From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christine Lemmer-Webber Newsgroups: gmane.emacs.devel Subject: Re: Access control in Emacs? Date: Wed, 15 Sep 2021 22:16:01 -0400 Message-ID: <87k0jhxnyz.fsf@dustycloud.org> References: <87h7en10sc.fsf@dustycloud.org> <00A34915-997B-463F-9898-5B6277724497@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8652"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.5; emacs 27.2 Cc: "emacs-devel@gnu.org" To: Qiantan Hong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 16 04:19:05 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQgzR-000261-52 for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Sep 2021 04:19:05 +0200 Original-Received: from localhost ([::1]:57332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQgzP-00039X-Ol for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Sep 2021 22:19:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50188) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQgyf-0002Oz-1W for emacs-devel@gnu.org; Wed, 15 Sep 2021 22:18:17 -0400 Original-Received: from dustycloud.org ([50.116.34.160]:58582) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQgyd-0002CA-1x for emacs-devel@gnu.org; Wed, 15 Sep 2021 22:18:16 -0400 Original-Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id B02BF2661B; Wed, 15 Sep 2021 22:18:12 -0400 (EDT) In-reply-to: <00A34915-997B-463F-9898-5B6277724497@mit.edu> Received-SPF: pass client-ip=50.116.34.160; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:274785 Archived-At: Qiantan Hong writes: > Hi Christine, > >> However, the path forward is *not* ACLs. These are a dangerous and >> error-prone direction: >>=20 >> http://waterken.sourceforge.net/aclsdont/current.pdf >>=20 >> Thankfully, we have much of the primitives to go in a safer >> direction... object capability security, which is a much better >> direction, is easily modeled on top of lexically scoped lisps, of which >> emacs lisp increasingly is supportive. See the following: >>=20 >> http://mumble.net/~jar/pubs/secureos/secureos.html > > Thanks for the references! Those are very informative, > and I=E2=80=99m recently thinking how to bring ocaps to Emacs, > however to avoid reinventing stuff (what=E2=80=99s worse, reinventing in = a wrong way) > I think discussion with someone more sophisticated at security will be he= lpful. > So, here=E2=80=99s what I=E2=80=99m thinking: > > To my understanding, to make a system capability-secure > one basically just need to eliminate or hide all ambient authority. > (One usually also require ways to store and transfer capabilities > but we have lambda and closure, so no need worrying about that). > > One apparent ubiquitous ambient authority in Emacs is name resolutions > to files in FS, buffers, processes etc.=20 > This is an easy fix. We can conveniently attach a text property to > the name strings as a proof of capability, and under capability-safe eval= uation > mode all name resolution procedures check this text property. > > Global/special variables are a more contrived case. > Do they count as ambient authority and also must be =E2=80=9Cfixed=E2=80= =9D? > How to do that? > One way I could think of is to have separate =E2=80=9Csandboxed global en= vironment=E2=80=9D > (we can hack it together by using a different obarray). > Then, to make capability-secure code to possibly affect the =E2=80=9Creal= =E2=80=9D global environment > we have to do some =E2=80=9Clinking=E2=80=9D between the =E2=80=9Csandbox= ed global environment=E2=80=9D and=20 > the =E2=80=9Creal=E2=80=9D one. Is this a reasonable/managable thing to d= o? > =E2=80=9CSandbox=E2=80=9D doesn=E2=80=99t sound like a good word. > Also in such cases it might be tedious to figure out the right set of va= riables to link, > especially if someone linked only part of the necessary variables=20 > the behavior could become unpredictable (in such case the sandboxed code > and the ambient code =E2=80=9Cdiverge=E2=80=9D on values of some variable= s that ought to be > shared but haven=E2=80=99t been). > > After all, does the general idea sketched above=20 > (capability-proof name string and sandboxed global environment) > sounds like reasonable security model? > What=E2=80=99re your thoughts on these specific issues mentioned above? > > > Best, > Qiantan Hi! Very short on time at the moment, so I'll speak briefly: you can take the "frozen realms" or "emaker" approach. Create a language sandbox with no ambient authority, where authority, such as filesystem access, has to be passed in, akin to how arguments are passed into a procedure. Rees's link above shows one way, the E emakers and Ecmascript "frozen realms" proposal another. Late here, so I can't do a better explainer of the core ideas, but hope that's a starting point for thinking.