From: Matthias Dahl <ml_emacs-lists@binary-island.eu>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
Subject: Re: security of the emacs package system, elpa, melpa and marmalade
Date: Thu, 26 Sep 2013 11:02:32 +0200 [thread overview]
Message-ID: <5243F828.6060901@binary-island.eu> (raw)
In-Reply-To: <87d2nw1j3b.fsf@uwakimon.sk.tsukuba.ac.jp>
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
next prev parent reply other threads:[~2013-09-26 9:02 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5243F828.6060901@binary-island.eu \
--to=ml_emacs-lists@binary-island.eu \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=stephen@xemacs.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.