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

[Stephen J. Turnbull]

Matthias Dahl writes:
 > Hello Stefan...
 > 
 > > Security problems in Emacs are everywhere, indeed.
 > 
 > Actually not quite the statement one wants to read _ever_ about the
 > software one loves to use. ;)
 > 
 > The question that is bugging me now: Why is that? Since Emacs, imho,
 > addresses a more technical audience and is maintained by professionals,
 > I wouldn't expect such a thing, actually.

Then your model of security is inadequate.  Software is *inherently*
insecure.  Any regular behavior provides an attack surface; large
amounts of regular behavior provides a large attack surface.  A single
breach of the attack surface and you lose.  Interfaces between
software systems are prolific sources of weak points.

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.

The fact that Emacs is mostly implemented in Lisp is also a security
feature, since it wraps, rather than calls directly, the system
functions.  This means that although such functions are available
(which is an attack vector), serious security breaches such as
exploiting a buffer overflow are hard to engineer, and the operating
system is likely to be able to protect itself from attacks via Lisp.

By the same token, as long as individual users have little power (for
example, not being able to bind to privileged ports), they're
generally not attractive targets for such attacks.  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.  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.

 > Hooks. If a security context is attached to a function (let's say
 > transitively through its package):
 > 
 >   function A is running with all permissions
 >   function A calls its hook
 >     each hook is executed within its own security context (=> narrowing)

    *pong* Function on function-hook doesn't have permission to frob.
    Allow frob? (0 = no; 1 = just this time; 2 = always; -1 = never) _

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.

For example, I don't know who's broken, but every time my "smart"
phone upgrades, I have to re-login to my employer's wireless network.
And every time, I'm told that the certificate can't be tracked to a
trusted root.  Of course the phone software is very little help in
figuring out what's wrong; it just shows the certificates.  I know how
to trace the transitive trust, but even so, why should I trust a
self-signed root claiming to be the Japanese Ministry of Education,
Science, and Technology's IT department?  These guys don't have
sufficient clue to get a path to a universally trusted root!  I also
am aware that sub-authorities have gone rogue or been hacked in the
past.  But ... I enable.  Wouldn't you?

Definitely my colleagues have no clue.  They don't even think about it
any more, so many servers present keys for a parent domain or sister
domain.  Even the CS Department (the initial entry point of the first
large-scale virus infection at my university after the virus checker
was installed on the mail gateway).  Most of these guys are theorists
(including in crypto where you'd think they'd be aware -- but no,
they're not) and have zero sysadmin experience (and probably haven't
read The Cuckoo's Egg).

 > Don't get me wrong, I'm not complaining or trying to force something.
 > Just trying raise a little awareness and maybe ignite some discussion
 > that potentially leads to a solution that improves overall
 > security.

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.