Re: Closing a privilege escalation

["Søren Pilgård" <fiskomaten@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

On Wed, Apr 25, 2018 at 6:47 PM, Glenn Morris <rgm@gnu.org> wrote:

>
> 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)?
>
>
If a clever hacker is able to run code on your computer as your account he
could just install a fake sudo program that snatches the password. And then
modify the path in your .bashrc etc. to execute this script instead of the
build in.

[-- Attachment #2: Type: text/html, Size: 2121 bytes --]