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: Tue, 14 Sep 2021 14:13:07 -0400 Message-ID: <87h7en10sc.fsf@dustycloud.org> References: 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="30471"; 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 Tue Sep 14 20:17:46 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 1mQD06-0007ji-7J for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Sep 2021 20:17:46 +0200 Original-Received: from localhost ([::1]:34514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQD04-0001us-5F for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Sep 2021 14:17:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQCy4-0000pU-CN for emacs-devel@gnu.org; Tue, 14 Sep 2021 14:15:40 -0400 Original-Received: from dustycloud.org ([50.116.34.160]:58580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQCxy-0000nV-42 for emacs-devel@gnu.org; Tue, 14 Sep 2021 14:15:39 -0400 Original-Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id BE3802661B; Tue, 14 Sep 2021 14:15:31 -0400 (EDT) In-reply-to: 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, T_SPF_TEMPERROR=0.01 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:274715 Archived-At: Qiantan Hong writes: > As I=E2=80=99m experimenting making Emacs a collaborative =E2=80=9COS=E2= =80=9D (using crdt.el), > I inevitably encountered this classical OS question. > I=E2=80=99m adding more powerful features to crdt.el including buffer loc= al variable > synchronizations and arbitrary remote command/function call, > however, it seems like they need to be accompanied by some access control > mechanism to be used =E2=80=9Creasonably safely=E2=80=9D. > > Now I=E2=80=99m not sure about how to achieve that, there=E2=80=99re seve= ral ways I can see: > 1. Really makes Emacs a multi-user OS. Add access control checks to=20 > all essential C primitives (which check against a current-user dynamic va= riable). > I don=E2=80=99t know how hard or intrusive it is. Does it worth it? > > 2. Another obvious thing I can do without touching massive amount of C co= de > is to add advice to interesting functions/primitives from Elisp side. Emacs's security model is atrocious, as in nonexistent, but we've lived with it anyway. However, the path forward is *not* ACLs. These are a dangerous and error-prone direction: http://waterken.sourceforge.net/aclsdont/current.pdf 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: http://mumble.net/~jar/pubs/secureos/secureos.html > However I think this is bad security design comparing to 1 because it can > possibly open lots of loop holes, especially privilege promotion. > Suppose we don=E2=80=99t want Ben Bitdiddle to read our FS, we may add an > advice to insert-file-contents that check against an ACL (which excludes = Ben). > However, if Ben has access to some other Lisp command that call some > C function that in turn calls insert-file-contents from C, the advice is = never > invoked and this is easy privilege promotion. > We can only wish that we wrote a set of access control rules that have so= me > =E2=80=9Cclosure=E2=80=9D property, however given that lots of Emacs comm= and are complex > and =E2=80=9Cintelligent=E2=80=9D, I don=E2=80=99t think this is manageab= le. > > I=E2=80=99m also not sure if extensive usage of advices is bad in a packa= ge supposedly > providing some fundamental feature. > I=E2=80=99m current using lots of advice already, to create =E2=80=9Cmock= =E2=80=9D buffer process object > that proxy I/O to a process on remote Emacs. > > 3. Or we can claim access control is for suckers. Trust your friends. Access control, or better yet, an authority system, is absolutely not for suckers. But access control lists are. Welcome to the world of confused deputies and ambient authority bugs. > Thoughts? > > > Best, > Qiantan