Access control in Emacs?

Access control in Emacs?

[Qiantan Hong]

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.

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.

Thoughts?


Best,
Qiantan

Re: Access control in Emacs?

[Phil Sainty]

Bug #45198 "Sandbox mode" may be of interest to you.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45198

Re: Access control in Emacs?

[dick]

QH> I’m experimenting making Emacs a collaborative OS ... adding
QH> arbitrary remote command/function call

A multi-user OS exists, and it is called UNIX.  It would be hard to improve
upon it.  What you seem to want is remote shell.  That also exists.  If port
forwarding or a simple X11 connection is not slick enough, there is
emacsclient.

When I was an undergrad, burning the candle on both ends was all I could
manage to keep my head above water, and I got Bs.  It would never occur to me
to write software outside classes, so much respect.

Re: Access control in Emacs?

[Qiantan Hong]

> A multi-user OS exists, and it is called UNIX.  It would be hard to improve
> upon it.  What you seem to want is remote shell.  That also exists.  If port
> forwarding or a simple X11 connection is not slick enough, there is
> emacsclient.
I don’t think UNIX is a particularly good multi-user OS — the access control
model is arbitrary and coarse grain. There’re improvements like SELinux,
but a CLOS generic function in Elisp will do much better.

But that’s rather a tangent. There are things that UNIX doesn’t attempt to do,
e.g. the collaboration aspect. I think the root cause is that although UNIX manages
shared state arguably well, it uses such a low level byte-stream model such that only
very few operations on shared state make sense. E.g. two users simultaneously editing
the same file just doesn’t work (because UNIX doesn’t really know edit nor text, it knows
read/write raw bytes).

I see Emacs potentially a much better platform for collaboration than UNIX,
however I must point out there’s already a great challenge from proprietary software.
I heard people saying m$’s VSCode server and live share blow emacs tramp 
(and I suppose current state of crdt.el) "out of water”.
They can share autocompletion, tags, debugger… etc,
and I’ve heard that it’s a killer feature for mentoring and attracting freshmen.

UNIX apparently doesn’t help with the above.
Let’s consider jump-to-definition. crdt.el already have all the facility to make it happen,
one peer sends jump-to-definition remote call request (we have to allow this!),
after the server run it, it finds itself possibly in a different buffer 
(we have to allow create buffer and file access!),
then in the post-command state synchronization phase the server
add the newly created buffer into the shared session (we have to configure this!)
and tell client to go into this buffer.

If I assume we allow everything, it’s a matter of 20 lines for me to implement
it on top of current crdt.el. And in general Emacs can easily surpass VSCode
in all collaboration aspect just because we start with a much more powerful piece
Of single-user software.
However there's grave security question.

> Given the way Emacs is designed/structured this is a recipe for big
> gaping security holes.  It can be OK to allow such things for *very*
> specific cases (a few specific well understood variables), but even such
> a "whitelist" is a problem because it requires careful and
> long term maintenance.

I think for Emacs to catch-up/surpass proprietary solutions there has
to be an extensible way to add remote command/variables, ideally
each package hackers could just add a few annotations to make
their packages work over shared sessions.

In the worst case we just outsource security to underlying OS
(ask host to run inside containers etc) but that might be too coarse grain...

Re: Access control in Emacs?

[dick]

> I don’t think UNIX is a good multi-user OS — Elisp will do much better.

User programs live in n-dimensions, and the OS is (n+1)-dimensional.  Emacs,
being a user program, cannot conceive of, much less create, an OS.

I believe the pair programming "best practice" pushed by McKinsey has largely
been debunked as "one guy doing all the work while the other guy slows him
down."

It's a brochure-worthy September day in the Northeast, the sickness be damned.
Get out there.  You know it's only like this for two weeks.

Re: Access control in Emacs?

[Stefan Kangas]

dick <dick.r.chiang@gmail.com> writes:
>
> > I don’t think UNIX is a good multi-user OS — Elisp will do much better.
>
> User programs live in n-dimensions, and the OS is (n+1)-dimensional.  Emacs,
> being a user program, cannot conceive of, much less create, an OS.

May I suggest that you indicate when you leave something out from a
quote with "[...]"?  In this case, your way of quoting makes it look
like something rather different from what was originally written: "I
don’t think UNIX is a particularly good multi-user OS — the access
control model is arbitrary and coarse grain. There’re improvements
like SELinux, but a CLOS generic function in Elisp will do much
better."

In other words, the author is saying that Elisp would be better for
implementing access control, not for implementing an OS.

Re: Access control in Emacs?

[Stefan Monnier]

> I’m adding more powerful features to crdt.el including buffer local variable
> synchronizations and arbitrary remote command/function call,

Given the way Emacs is designed/structured this is a recipe for big
gaping security holes.  It can be OK to allow such things for *very*
specific cases (a few specific well understood variables), but even such
a "whitelist" is a problem because it requires careful and
long term maintenance.


        Stefan

Re: Access control in Emacs?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I’m adding more powerful features to crdt.el including buffer local variable
  > > synchronizations and arbitrary remote command/function call,

  > Given the way Emacs is designed/structured this is a recipe for big
  > gaping security holes.  It can be OK to allow such things for *very*
  > specific cases (a few specific well understood variables), but even such
  > a "whitelist" is a problem because it requires careful and
  > long term maintenance.

This is a crucial issue, so we should keep it in mind if we change
anything that affects the handling of buffer-local variables.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Access control in Emacs?

[Robin Tarsiger]

Stefan Monnier wrote:
>> I’m adding more powerful features to crdt.el including buffer local variable
>> synchronizations and arbitrary remote command/function call,
> 
> Given the way Emacs is designed/structured this is a recipe for big
> gaping security holes.  It can be OK to allow such things for *very*
> specific cases (a few specific well understood variables), but even such
> a "whitelist" is a problem because it requires careful and
> long term maintenance.
For the buffer-local variables specifically, we do already have
safe-local-variable-p which might cover a number of cases---and
that's already used for loading variables from untrusted files.
That said, that mechanism is still dangerous on an absolute scale
and has had security holes in the past (one of which I PoC'd and
reported myself decades ago, though I can't find it now).

Remote commands would be even more dangerously tricky to get right,
especially in the absence of ground-up infrastructure for it.

-RTT

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

Re: Access control in Emacs?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

On Tue, Sep 14, 2021 at 02:13:07PM -0400, Christine Lemmer-Webber wrote:

[...]

> However, the path forward is *not* ACLs.  These are a dangerous and
> error-prone direction:

[...]

Not the OP here, but thanks for the interesting links :)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Access control in Emacs?

[Qiantan Hong]

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

Re: Access control in Emacs?

[Christine Lemmer-Webber]

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.

Re: Access control in Emacs?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Why implement this access control in Emacs?
Wouldn't it be more useful if it were independent of Emacs?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)