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

Previous Next

Full log

Message #53 received at 75017 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acorallo <at> gnu.org, jm <at> pub.pink, monnier <at> iro.umontreal.ca,
 75017 <at> debbugs.gnu.org
Subject: Re: bug#75017: 31.0.50; Untrusted user lisp files
Date: Mon, 23 Dec 2024 14:10:30 +0000

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

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Sun, 22 Dec 2024 17:36:15 +0000
>> Cc: jm <at> pub.pink, 75017 <at> debbugs.gnu.org, acorallo <at> gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> >> Cc: john muhl <jm <at> pub.pink>,  75017 <at> debbugs.gnu.org,  Eli Zaretskii
>> >>  <eliz <at> gnu.org>,  Andrea Corallo <acorallo <at> gnu.org>
>> >> Date: Sat, 21 Dec 2024 22:16:05 -0500
>> >>
>> >> > Maybe we should install something like the below?
>> >>
>> >> Fine by me, but I think this should be added via a new
>> >> `trusted-content-function(s)` and added buffer-locally only in
>> >> elisp-mode buffers.
>> >
>> > Sorry, but this is slippery slope.  For starters, no one said that
>> > site-run-file is installed by a sysadmin -- that is only so on certain
>> > systems.  For example, MS-Windows is generally not in that category.
>>
>> It doesn't matter who can edit it.  `site-run-file` is already trusted,
>> since it is loaded at run-time before `user-init-file`.
>
> It is loaded if it is there.  On my system, there's no such file, and
> I don't expect to have it.

This seems orthogonal to the issue at hand.

If you don't want to load `site-run-file`, you should use the
--no-site-file flag.  (We should probably take that flag into account
when saying if that file is `trusted-content-p` though.)

Without that flag, we load files in these well-known locations
unconditionally.  In my view, it then makes little sense to worry about
loading any `eval-when-compile` forms (or similar) in these files when
byte-compiling them.  If they contain malicious code, that code has
already been run when Emacs started, or it will be run the next time
Emacs starts (e.g., if it has been modified after Emacs started).

In other words, this case is quite analogous to `user-init-file`.

> So if such a file somehow materializes there, I want to know, pronto.

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

But to do what you suggest, we would need to start with deciding under
what circumstances it is not expected to find a file in this location,
and then not just warn but refuse to load it if it meets that criteria.
I don't know how to design such criteria.

If we can figure out a way to do that, then I agree that it would be
consistent not to treat this file as `trusted-content-p`, when it exists
unexpectedly.

Previous Next

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