GNU bug report logs - #75017
31.0.50; Untrusted user lisp files

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dmitry <at> gutov.dev>
Cc: jm <at> pub.pink, 75017 <at> debbugs.gnu.org
Subject: bug#75017: 31.0.50; Untrusted user lisp files
Date: Mon, 23 Dec 2024 14:36:35 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Sun, 22 Dec 2024 22:27:34 +0200
>> Cc: stefankangas <at> gmail.com, jm <at> pub.pink, 75017 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>> On 22/12/2024 22:23, Eli Zaretskii wrote:
>> >> And Emacs will load whatever's written there on the next restart.
>> >> Whether the user wrote to those files, or someone else.
>> > Yes, and your point is..?
>>
>> That whatever malicious code we try to protect against using the
>> "trusted content" mechanism would be executed anyway.
>
> The scenario I have in mind is this:
>
>   . Emacs session is running; when it was started, there was no
>     site-init file
>   . User notices that site-init file appeared
>   . User visits the site-init file
>   . Malicious macro in site-init file is executed
>
> IOW, there could be valid situations where the user visits the file
> before restarting Emacs (which would load the file).  In these
> situations, it would make sense to treat the file as not trusted --
> unless the user tells us it should always be unconditionally trusted.

Thanks, I saw this post after sending my most recent reply.  I think the
above scenario is valid, but I don't think it's common.

However, if we want to mitigate that specific scenario, maybe we should
only treat `site-init-file` as `trusted-content-p` if a site-file
existed on Emacs startup.

While I do see a difference between `user-init-file` and
`site-init-file`, I think we should treat this set of files as
equivalent when it comes to `trusted-content-p`:

  user-init-file
  early-init-file
  site-init-file

Either they should all be `trusted-content-p`, or none of them should.
In other words, I believe that this part of my reply also still stands:

SK> First, I note that it's likely already game over if an attacker can
SK> write to `site-init-file`, because they can then just as easily write
SK> to your init file (or other relevant files in `load-path`) instead.

BTW, this all shows that Stefan Monnier is correct when he laments that
"trust sucks".  It really does.  We should implement proper sandboxing
when byte-compiling these files, using bwrap or similar.  Only when that
is done, can we have reasonably strong security guarantees.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.