unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Access control in Emacs?
@ 2021-09-14 12:49 Qiantan Hong
  2021-09-14 14:09 ` Phil Sainty
                   ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: Qiantan Hong @ 2021-09-14 12:49 UTC (permalink / raw)
  To: emacs-devel

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 12:49 Access control in Emacs? Qiantan Hong
@ 2021-09-14 14:09 ` Phil Sainty
  2021-09-14 14:28 ` dick
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 14+ messages in thread
From: Phil Sainty @ 2021-09-14 14:09 UTC (permalink / raw)
  To: Qiantan Hong; +Cc: emacs-devel

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

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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 12:49 Access control in Emacs? Qiantan Hong
  2021-09-14 14:09 ` Phil Sainty
@ 2021-09-14 14:28 ` dick
  2021-09-14 15:05   ` Qiantan Hong
  2021-09-14 14:49 ` Stefan Monnier
  2021-09-14 18:13 ` Christine Lemmer-Webber
  3 siblings, 1 reply; 14+ messages in thread
From: dick @ 2021-09-14 14:28 UTC (permalink / raw)
  To: Qiantan Hong; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 12:49 Access control in Emacs? Qiantan Hong
  2021-09-14 14:09 ` Phil Sainty
  2021-09-14 14:28 ` dick
@ 2021-09-14 14:49 ` Stefan Monnier
  2021-09-15 20:11   ` Richard Stallman
  2021-09-15 20:21   ` Robin Tarsiger
  2021-09-14 18:13 ` Christine Lemmer-Webber
  3 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier @ 2021-09-14 14:49 UTC (permalink / raw)
  To: Qiantan Hong; +Cc: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 14:28 ` dick
@ 2021-09-14 15:05   ` Qiantan Hong
  2021-09-14 15:52     ` dick
  0 siblings, 1 reply; 14+ messages in thread
From: Qiantan Hong @ 2021-09-14 15:05 UTC (permalink / raw)
  To: dick, Stefan Monnier; +Cc: emacs-devel

> 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...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 15:05   ` Qiantan Hong
@ 2021-09-14 15:52     ` dick
  2021-09-14 16:02       ` Stefan Kangas
  0 siblings, 1 reply; 14+ messages in thread
From: dick @ 2021-09-14 15:52 UTC (permalink / raw)
  To: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 15:52     ` dick
@ 2021-09-14 16:02       ` Stefan Kangas
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Kangas @ 2021-09-14 16:02 UTC (permalink / raw)
  To: dick; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 12:49 Access control in Emacs? Qiantan Hong
                   ` (2 preceding siblings ...)
  2021-09-14 14:49 ` Stefan Monnier
@ 2021-09-14 18:13 ` Christine Lemmer-Webber
  2021-09-14 19:59   ` tomas
  2021-09-15 23:16   ` Qiantan Hong
  3 siblings, 2 replies; 14+ messages in thread
From: Christine Lemmer-Webber @ 2021-09-14 18:13 UTC (permalink / raw)
  To: Qiantan Hong; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 18:13 ` Christine Lemmer-Webber
@ 2021-09-14 19:59   ` tomas
  2021-09-15 23:16   ` Qiantan Hong
  1 sibling, 0 replies; 14+ messages in thread
From: tomas @ 2021-09-14 19:59 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 14:49 ` Stefan Monnier
@ 2021-09-15 20:11   ` Richard Stallman
  2021-09-15 20:21   ` Robin Tarsiger
  1 sibling, 0 replies; 14+ messages in thread
From: Richard Stallman @ 2021-09-15 20:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: qhong, emacs-devel

[[[ 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)





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 14:49 ` Stefan Monnier
  2021-09-15 20:11   ` Richard Stallman
@ 2021-09-15 20:21   ` Robin Tarsiger
  1 sibling, 0 replies; 14+ messages in thread
From: Robin Tarsiger @ 2021-09-15 20:21 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-14 18:13 ` Christine Lemmer-Webber
  2021-09-14 19:59   ` tomas
@ 2021-09-15 23:16   ` Qiantan Hong
  2021-09-16  2:16     ` Christine Lemmer-Webber
  1 sibling, 1 reply; 14+ messages in thread
From: Qiantan Hong @ 2021-09-15 23:16 UTC (permalink / raw)
  To: Christine Lemmer-Webber; +Cc: emacs-devel

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-15 23:16   ` Qiantan Hong
@ 2021-09-16  2:16     ` Christine Lemmer-Webber
  2021-09-18  0:29       ` Richard Stallman
  0 siblings, 1 reply; 14+ messages in thread
From: Christine Lemmer-Webber @ 2021-09-16  2:16 UTC (permalink / raw)
  To: Qiantan Hong; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Access control in Emacs?
  2021-09-16  2:16     ` Christine Lemmer-Webber
@ 2021-09-18  0:29       ` Richard Stallman
  0 siblings, 0 replies; 14+ messages in thread
From: Richard Stallman @ 2021-09-18  0:29 UTC (permalink / raw)
  To: Christine Lemmer-Webber; +Cc: qhong, emacs-devel

[[[ 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)





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-09-18  0:29 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-14 12:49 Access control in Emacs? Qiantan Hong
2021-09-14 14:09 ` Phil Sainty
2021-09-14 14:28 ` dick
2021-09-14 15:05   ` Qiantan Hong
2021-09-14 15:52     ` dick
2021-09-14 16:02       ` Stefan Kangas
2021-09-14 14:49 ` Stefan Monnier
2021-09-15 20:11   ` Richard Stallman
2021-09-15 20:21   ` Robin Tarsiger
2021-09-14 18:13 ` Christine Lemmer-Webber
2021-09-14 19:59   ` tomas
2021-09-15 23:16   ` Qiantan Hong
2021-09-16  2:16     ` Christine Lemmer-Webber
2021-09-18  0:29       ` Richard Stallman

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).