Re: Access control in Emacs?

[Christine Lemmer-Webber]

Qiantan Hong <qhong@mit.edu> writes:

> As I’m experimenting making Emacs a collaborative “OS” (using crdt.el),
> I inevitably encountered this classical OS question.
> I’m adding more powerful features to crdt.el including buffer local 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 “reasonably safely”.
>
> Now I’m not sure about how to achieve that, there’re several ways I can see:
> 1. Really makes Emacs a multi-user OS. Add access control checks to 
> all essential C primitives (which check against a current-user dynamic 
> variable).
> I don’t know how hard or intrusive it is. Does it worth it?
>
> 2. Another obvious thing I can do without touching massive amount of C code
> 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’t 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 some
> “closure” property, however given that lots of Emacs command are complex
> and “intelligent”, I don’t think this is manageable.
>
> I’m also not sure if extensive usage of advices is bad in a package supposedly
> providing some fundamental feature.
> I’m current using lots of advice already, to create “mock” 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