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

[Matthias Dahl <ml_emacs-lists@binary-island.eu>]

Hello Stefan...

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

Which is absolutely fabulous and will make it harder to temper with
packages on one of the package repositories. Suffice to say, this won't
do anything for preventing malicious code from (a hacked) upstream
slipping through -- and this approach is not feasible for MELPA which is
becoming (afaict) more and more popular these days.

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

The situation with Debian (and any other well maintained distro) is a
bit different, imho. There are dedicated distro maintainers taking care
of their packages and some distros also have a QA procedure. There are
usually just more eyes watching and testing. Also, a lot of those
upstream projects have a team of people working on their project which
will make tempering on a decent dvcs easier to spot.

In the Emacs ecosystem, people take code from the wiki or from any of
the package repositories, knowing nothing about usually the single
person who wrote said package... especially nothing about how security
of their accounts is handled in terms of passwords, pubkeys and
whatever. So a github could get hacked, malicious code placed without
the maintainer even noticing for a very long period because he just
moved on. And so on...

Granted, those are all absolutely worst-case scenarios and one could
argue for days about how likely and relevant such incidents really are.

But apart from that, there is naturally also the other side: Security
leaks due to bad code caused simply by inexperience which could be
exploited.

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

I've been thinking about this really hard as well. And I've to admit,
I'm not (at least not yet) an Emacs/elisp expert. But not every package
needs to overwrite some core functions.

One idea thrown into discussion: We could differentiate between core and
non-core functions. This would allow the introduction of a new
permission like "re-define core function"... which naturally is like
granting a program root access.

A core function could be, imho, any function that comes bundled with
Emacs when it starts up - possibly including init.el and the user's
modifications. If the user decides to load packages on his own, we could
provide a new argument to load-file to pass a permission context in.

And naturally, to avoid any priviledge escalation, we'd only allow
permission narrowing and never widening. But I already touched that in
my last mail.

I agree, such a "sandbox" project would be quite an endeavour to take on
and would require a great deal of careful designing and implementing.

The question is this: Would there be any interest and motivation from
the current dev community to drive such an endeavour? Because otherwise
such a project would be doomed to fail, imho.

Sorry for my late reply, by the way. I am currently fighting a nasty
kind of human virus. I already tried putting my hand on the CPU and
running an anti-virus scanner which surprisingly did not work. ;-)

So long,
Matthias

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