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

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

Hello Stephen...

> Then your model of security is inadequate.  Software is *inherently*
> insecure.

Agreed. But if someone says there are security leaks all over the place,
that is a different story. This implies those are tolerated for various
reasons. But they do exist and should be fixed, nevertheless.

I would _never_ consider a software secure. But if holes exist that are
known and those are not fixed, that is a different story. This does also
imply that code slips in that lacks in quality... knowingly.

> Emacs provides a huge attack surface on the individual user *because*
> it is so capable, and provides interfaces to so many other software
> systems.  That's all there is to it.

Agreed. But this doesn't imply that the user should be powerless against
each and every plugin he installs. One can assume that the Emacs code
base does not contain any malicious code and is thus "secure" at least
in this regard. Naturally there are holes - known and unknown. The key,
imho, is to empower the user to have more control over plugins he needs
to install. This adds a line of defense that can be built upon.

Right now there is absolutely nothing stopping a hacked plugin to do
just about anything until the community or the user somehow notices this.

> If they are attacked (eg, to get a privilege escalation started), the attacker
> will eschew use of Emacs and head straight for the C compiler.

Emacs can "easily" be used through a malicious plugin to tamper with the
user environment and thus gain all kinds of access and data. It does not
need to really make any use of a security hole / leak.

> That,
> combined with the relative security of Lisp itself, means that the
> incentive for Emacs developers to put in the necessary effort for a
> serious security audit and a complete redesign of the Lisp
> implementation is rather low.

That is only half of the story, though. My concern mainly lies with the
"plugin" system. Putting some kind of defense there. And yes, in the end
this would also possibly mean to harden Emacs here and there to protect
this defense system from being tampered with.

Things are more intervened than your point of view suggests.

> But this is really self-defeating.  Since in general hooks should be
> empty by default, what you're saying is that a function that the user
> has probably explicitly specified and may have written herself should
> run with less privilege than functions that the user is only vaguely
> aware of.

Only thoughts. I was only thinking aloud. :) Again, all of this would
need a lot more detailing and testing, obviously.

But in general, I would consider user code in the same category as core
code, thus full privileges. Now if a function with less privileges
called a hook that contains a function with required higher privileges,
that would naturally be a very valid use-case that would need further
investigation for a suitable solution.

>  But ... I enable.  Wouldn't you?

But at least you get a warning. You get information. You can make an
informed decision at that time. You do know who you are dealing with,
you can somehow at least rudimentarily assess the risks for this very
specific case.

With Emacs, you can either review each and every change for each and
every plugin you have installed - or you are completely on your own.
There are no warnings. No checks. Nothing.

To expand on your good example: This would be like you had to check the
certs all by yourself beforehand by logging in, tracing and validating
everything. If you did not do so, well, your choice... and there would
be no warning or checks. Nothing.

And not everybody uses self-signed certs, by the way. ;) Even though the
cert system is broken in several aspects, it still provides some from of
valuable clue whether a site (in the most general meaning of the term)
is most likely "trustworthy" or not.

> I'm sure the leadership is aware.  But the basic answer is the same as
> in any security context: avoid exposing regular behavior to potential
> enemies, and establish a community watch on community resources.

And what would you suggest in terms of ELPA / Marmalade and MELPA and
the package system in general based on this...?

By the way, thanks for your input. It is very much appreciated.

So long,
Matthias

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