Re: Access control in Emacs?

[Christine Lemmer-Webber <cwebber@dustycloud.org>]

Qiantan Hong <qhong@mit.edu> writes:

> Hi Christine,
>
>> 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
>
> Thanks for the references! Those are very informative,
> and I’m recently thinking how to bring ocaps to Emacs,
> however to avoid reinventing stuff (what’s worse, reinventing in a wrong way)
> I think discussion with someone more sophisticated at security will be helpful.
> So, here’s what I’m 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. 
> 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 evaluation
> 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 “fixed”?
> How to do that?
> One way I could think of is to have separate “sandboxed global environment”
> (we can hack it together by using a different obarray).
> Then, to make capability-secure code to possibly affect the “real” global environment
> we have to do some “linking” between the “sandboxed global environment” and 
> the “real” one. Is this a reasonable/managable thing to do?
> “Sandbox” doesn’t sound like a good word.
> \bAlso in such cases it might be tedious to figure out the right set of variables to link,
> especially if someone linked only part of the necessary variables 
> the behavior could become unpredictable (in such case the sandboxed code
> and the ambient code “diverge” on values of some variables that ought to be
> shared but haven’t been).
>
> After all, does the general idea sketched above 
> (capability-proof name string and sandboxed global environment)
> sounds like reasonable security model?
> What’re 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.