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

[Matthias Dahl]

Hello @all,

I know there has been a thread about (more or less) this topic sometime
last year, iirc. But I was unable to find something current, so I hope
it is okay to raise a few questions and ideas about this subject.

As it stands, most Emacs users I guess install quite a few packages from
various sources (git repo, elpa, melpa, ...) to mold Emacs to their very
specific needs and workflow. The same naturally goes for me.

Right now, the only way to make sure there is no malicious code hidden
in those packages, is to check each one manually during the initial
installation as well as for each update... which can be a very time
intensive task and not every person using Emacs is a Elisp guru and can
really spot each malicious code fragment. Especially since more and more
newer projects recommend installing their package through the package
management system (especially MELPA) which makes it even more easy to
install something without checking it first.

Signed packages on the package server (e.g. ELPA) make sense, if said
process is done externally and a security check is performed on the
package in question before signing. For MELPA this is an even harder
problem to solve, since it is fully automated and thus even signing the
package is out of the question since it would not add much of a value.

Nevertheless, I think this is a serious problem and a security incident
waiting to happen... it is just a matter of time, imho.

The best solution imho would be that each package on a package server,
no matter which one, is reviewed before being available either through a
dedicated staff of volunteers or through a more open process that makes
use of the user base somehow (which could be very difficult in terms of
trustworthiness). Unfortunately, I see this as something that needs
annual financial funding and hard for the Emacs community to achieve. I
might be wrong - and I'd like to be, honestly.

So, I'd like to propose the following as at least some measure of
protection and a first step in making the package system more secure: A
package gets a security context which details its very own permissions
just like e.g. an Android app. That context is permanent, meaning that
if a user action enters package 1 with a narrow permission set which in
turn utilizes some functions of a package 2 (which has a rather wide
permission set), only the original narrow permission set will be applied
and available. This makes the implementation easier and the system more
robust against possible workaround/exploits, imho.

There are a lot of packages that don't need access to the filesystem,
network and other security sensitive areas. If a package got hacked that
did not have those permissions in the first place, Emacs could detect a
violation, inform the user and end the execution.

Naturally, this also implies that the defined permissions should only be
alterable on the package server through an authoritative person and not
by the package itself. Also, if permissions changed, the user would
be informed by Emacs and ask for permission.

This would need a lot more detailing like what kind of permissions
should be defined (granularity, ...) and how. I'm just throwing my
thoughts into the community hive mind, very much hoping not to get
crushed fiercely. :)

Basically, all I want to achieve with this mail is to get a discussion
going about this topic which hopefully could lead to a more secure and
even better Emacs package system.

Sorry for the wall of text... and thanks for listening, um, reading. :)

-- 
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
 services: custom software [desktop, mobile, web], server administration