bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 22 Dec 2024 22:27:34 +0200
>> Cc: stefankangas@gmail.com, jm@pub.pink, 75017@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@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.