Re: security of the emacs package system, elpa, melpa and marmalade

["Óscar Fuentes" <ofv@wanadoo.es>]

Matthias Dahl <ml_emacs-lists@binary-island.eu> writes:

[snip]

>   As a counter example: Plugins distributed through addons.mozilla.org
>   are checked for security - initial versions as well as updates.

I don't think that comparing Emacs to a web browses used by tens of
millions is fair. The later is a major attack target/vector for any
crook, while Emacs is mostly uninteresting. No matter all the effort the
Mozilla guys put on security, it is their web browser the real security
threat on your system, not Emacs.

> - An Emacs plugin can do whatever it chooses to do with the full
>   privileges of the current user. But why give a plugin all such power
>   in the first place? Informing the user beforehand what privileges a
>   plugin required and thus tightening the belt on a plugin, would make
>   things more transparent and more secure.

Yes, sure. And I think that it can be achieved without too much effort
(read: without rewriting whole chunks of Emacs code.)

Add support for declaring the capabilities the .el file being read
requires: write access to the filesystem, network I/O, running
processes, etc. Encode that on a data structure (a plain integer would
do) associated to each function on that .el file. Then, when a function
is executed its permissions becomes effective and are checked by the
primitive functions that implement the sensitive operation. Of course,
when function F calls function G the permissions of F are effective over
G, on a restrictive way. Also, it could be possible to declare "safe"
functions which privileges can override the caller permissions on a
permissive way. Those functions would be on the Emacs core, of course.

I guess that this schema would require minimal changes to the
interpreter, byte compiler and core functions that perform sensitive
operations. On exchange, the user would know that such and such packages
are not allowed to send his all-important files through the internet,
nor delete his entire home directory.

[snip]