all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Glenn Morris <rgm@gnu.org>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: Closing a privilege escalation
Date: Wed, 25 Apr 2018 12:47:30 -0400	[thread overview]
Message-ID: <vsfu3jjkrh.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <E1fB8vq-0002wh-19@fencepost.gnu.org> (Richard Stallman's message of "Tue, 24 Apr 2018 21:09:14 -0400")


This was previously discussed in bug#28618.
I think the discussion suffers from lack of a clear example, so let me
try to give one:

A normal (uncompromised) user account inadvertently installs a malicious
Emacs package that contains exploit code that waits to be run as root.

This user then sudos (to root) in such a way that HOME is not reset to
that of root. They then run Emacs, which executes the malicious package
code as root.

This entire class of exploit can be avoided by suitable sudo options
(always_set_home etc), but that doesn't necessarily mean that Emacs
should not do something about it.

It seems to me, that "if UID = 0, set user-init-file, user-emacs-directory
etc to those of root" is a simpler solution that the one you propose.

This effectively enforces the always_set_home feature of sudo in Emacs.
This may annoy some people, but you can't make the behaviour optional,
because then the bad code could disable it. Some might say that people
using sudo without set_home want the behaviour the way it is now, but
maybe we could argue that it is not always a conscious choice.

By the way, what about sudo called from Tramp? Let's suppose the
malicious package subverts the sudo syntax that is built-in to Emacs.
How to defend against that (ie people running sudo within Emacs)?



  parent reply	other threads:[~2018-04-25 16:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25  1:09 Closing a privilege escalation Richard Stallman
2018-04-25  1:18 ` Noam Postavsky
2018-04-25 22:40   ` Richard Stallman
2018-04-25  1:29 ` Lars Ingebrigtsen
2018-04-25 22:40   ` Richard Stallman
2018-04-26  7:20     ` Lars Ingebrigtsen
2018-04-26  7:52       ` Lars Ingebrigtsen
2018-04-26 21:05       ` Richard Stallman
2018-04-26 21:26         ` Tim Cross
2018-04-27 15:57           ` Richard Stallman
2018-04-27  9:50         ` Marcin Borkowski
2018-04-27 14:29           ` Clément Pit-Claudel
2018-04-25 15:25 ` Davis Herring
2018-04-25 16:47 ` Glenn Morris [this message]
2018-04-25 17:09   ` Stefan Monnier
2018-04-25 17:12     ` Stefan Monnier
2018-04-25 17:55     ` Paul Eggert
2018-04-26 21:01     ` Richard Stallman
2018-04-25 17:10   ` Søren Pilgård

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=vsfu3jjkrh.fsf@fencepost.gnu.org \
    --to=rgm@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.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.