emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matthias Dahl
Subject: Re: security of the emacs package system, elpa, melpa and marmalade
Date: Wed, 25 Sep 2013 20:31:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

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. Especially since it is not
written in such a commong language that everyone learns during their
first years in high-school or university which implies a certain level
of interest and knowledge in programming if one decides to tackle lisp.

Regarding your examples: You are absolutely right, it is a tough problem
to solve... especially without sacrificing any freedom that everyone has
come to love about Emacs. And it would require more than just one person
trying to get this done.

Zooming out a bit: A major mode that wants to run external programs
could either define them through its permission file which would _not_
be part of its package but some properties on the package server that
can only be changed by its staff. Or Emacs could ask the user the first
time, if it is okay to execute the following programs with arguments xyz
and remember that change. All of those security relevant data should go
into a separate file naturally that Emacs protects from access, so a
plugin could not tamper with the datastore and gain priviledges that way
after a restart.

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)

I'm just throwing my thoughts in the mix at this time. All this would
need a lot more thought and work, obviously. But I honestly think this
would be a goal worth pursuing since security should never be taken
lightly, imho. Nevertheless if there is zero traction from the community
such a project would be doomed to fail. And right now, we are the only
two in this discussion which could be seen as a lack of interest. :(

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.

Thanks Stefan by the way for taking the time. Much appreciated.

So long,
Matthias

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]