unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Matthias Dahl <ml_emacs-lists@binary-island.eu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: security of the emacs package system, elpa, melpa and marmalade
Date: Wed, 25 Sep 2013 20:31:05 +0200	[thread overview]
Message-ID: <52432BE9.1070402@binary-island.eu> (raw)
In-Reply-To: <jwvob7gx43e.fsf-monnier+emacs@gnu.org>

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	other threads:[~2013-09-25 18:31 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-23  7:30 security of the emacs package system, elpa, melpa and marmalade Matthias Dahl
2013-09-23 14:17 ` Stefan Monnier
2013-09-25  8:11   ` Matthias Dahl
2013-09-25 17:00     ` Stefan Monnier
2013-09-25 18:31       ` Matthias Dahl [this message]
2013-09-25 22:42         ` Bastien
2013-09-26  9:02           ` Matthias Dahl
2013-09-27 14:02             ` Bastien
2013-09-27 14:17               ` Matthias Dahl
2013-09-27 14:19                 ` Bastien
2013-09-27 18:29                   ` Matthias Dahl
2013-09-26  1:09         ` Stefan Monnier
2013-09-26  9:02           ` Matthias Dahl
2013-09-26  9:21             ` Óscar Fuentes
2013-09-26 14:41             ` Stefan Monnier
2013-09-27 14:17               ` Matthias Dahl
2013-09-27 15:47                 ` Stefan Monnier
2013-09-28 14:15                   ` Richard Stallman
2013-09-30 15:12                     ` Matthias Dahl
2013-09-30 21:11                       ` Richard Stallman
2013-09-30 15:31                   ` Matthias Dahl
2013-09-26  1:12         ` Stephen J. Turnbull
2013-09-26  9:02           ` Matthias Dahl
2013-09-27  7:10             ` Stephen J. Turnbull
2013-09-27 14:18               ` Matthias Dahl
2013-09-27 17:31                 ` Stephen J. Turnbull
2013-09-30 15:25                   ` Matthias Dahl
2013-10-01  2:19                     ` Stephen J. Turnbull
2013-09-27 20:12                 ` chad
2013-09-26  9:31           ` Andreas Röhler
2013-09-26 16:25           ` Richard Stallman
2013-09-27 14:18             ` Matthias Dahl
2013-09-27 15:04               ` Óscar Fuentes
2014-09-13 17:57                 ` Thomas Koch
2013-09-29 10:12             ` Ted Zlatanov
2013-09-29  9:53   ` Ted Zlatanov
2013-09-29 17:49     ` Daiki Ueno
2013-09-29 18:18       ` Ted Zlatanov
2013-09-30 13:25         ` Ted Zlatanov
2013-09-30 14:50           ` Stephen J. Turnbull
2013-09-30 15:10     ` Matthias Dahl
2013-09-30 17:18       ` Ted Zlatanov
2013-10-01 14:03         ` Matthias Dahl
2013-10-02  2:45           ` Stephen J. Turnbull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52432BE9.1070402@binary-island.eu \
    --to=ml_emacs-lists@binary-island.eu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).