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

[Ted Zlatanov]

On Mon, 23 Sep 2013 10:17:33 -0400 Stefan Monnier <address@hidden> wrote: 

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

SM> The current state, AFAIK is that we decided that ELPA servers should
SM> put *.gpg signatures alongside their tarballs and other files, signed
SM> with an "archive" key.  This signature can be used to check that the
SM> package you get indeed comes from that archive.

SM> In terms of code, it's not implemented yet, AFAIK (IIRC Ted is working
SM> on it).

VERY slowly.  I tried to get back to it, only to find out (see other
thread under subject "bad epg.el+GPG2 behavior: unavoidable passphrase
pinentry prompt") that GPG2 is practically unusable.  Frustrating.

As I've mentioned in the past, I dislike relying on an external binary
like GPG to do encryption so this is pushing me again towards a more
built-in Lispy way to do signing of packages.  Opinions welcome,
especially if you can think of a way that Emacs can sign files in a
similar way to GPG keys in Lisp.

In any case, I posted a patch (probably needs to be rewritten by now)
which intercepted package.el file requests and required an additional
.sig file that signed the file.  So any file, tarball, or index requires
a maintainer signature to be used.

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

SM> Not gonna happen, indeed.  It doesn't happen for Debian either, FWIW, so
SM> it's usually not considered as a very major problem.

SM> W.r.t. GNU ELPA packages, every commit installed send an email
SM> containing the diff to a mailing-list to which some people are
SM> subscribed, so there is a bit of review there, but it's far from
SM> sufficient to prevent introduction of security problems.

Stefan, I don't know if you remember it the same way, but when I worked
with you on getting ELPA started, I recall I had the maintainer rolling
out updates manually after review.  We added the cron job later (maybe I
was involved, I honestly don't remember) but I definitely wanted to
avoid the current situation where updates to GNU ELPA packages get
rolled out straight to our users without review.

Unlike VCS updates, the GNU ELPA updates go to live users who don't know
they may be using bleeding-edge or risky code, and IMHO should be gated
by some kind of maintainer review or at least marked as "unreviewed
update" in the UI.  The auto-merging of external repos is an even bigger
issue; again we need to establish a wall between developers and our live
users but here we trust external groups of contributors to DTRT.

I would propose using the signature files above to provide that wall,
so auto-signing should not be done.  Instead a maintainer team should
review changes that need to go up on the GNU ELPA.

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

SM> Sandboxing could be an interesting direction, but it seems very
SM> difficult: not only it'll be a non-trivial amount of implementation
SM> work, but even just designing it will be difficult, due to the current
SM> nature of Emacs's design where everything is global and shared.

There are too many ways to compromise Emacs Lisp because it was not
written with security in mind.  Also see my previous proposals for
secure data storage in Emacs, which would certainly be relevant if we
consider external packages as a possible attack vector.  Even that
relatively minor improvement has met significant resistance; I would
imagine a full security-oriented redesign would be as popular as
SELinux.

Ted