bug#75017: 31.0.50; Untrusted user lisp files

bug#75017: 31.0.50; Untrusted user lisp files

[john muhl]

user-init-file is trusted by default but not other user files.

  C-xf ~/.emacs.d/early-init.el
  M-x flymake-mode

Produces a warning:

  Disabling elisp-flymake-byte-compile in early-init.el (untrusted content)

custom-file (when not the same as user-init-file) also causes a
warning. Should these also be trusted by default?

What about files put in place by a system admin or your distro’s
Emacs package (e.g. site-run-file, default.el)? They generally
require root priviledges to install so if they can’t be trusted
you’re already in trouble.




In GNU Emacs 31.0.50 (build 87, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.2) of 2024-12-21 built on thelio
 Repository revision: ff4fcfc92cd80c9dbc68855549102d07ef419268
 Repository branch: master
 System Description: Fedora
 Linux 41 (Workstation Edition)

Configured using:
 'configure --with-pgtk --prefix=/home/jm/opt'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS
TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  server-mode: t
  bug-reference-prog-mode: t
  bug-reference-mode: t
  completion-preview-mode: t
  outline-minor-mode: t
  ruler-mode: t
  winner-mode: t
  savehist-mode: t
  repeat-mode: t
  midnight-mode: t
  global-visual-wrap-prefix-mode: t
  visual-wrap-prefix-mode: t
  global-paren-face-mode: t
  paren-face-mode: t
  global-goto-address-mode: t
  goto-address-mode: t
  global-auto-revert-mode: t
  electric-pair-mode: t
  dynamic-completion-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  auto-insert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-quote-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  auto-save-visited-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug magit-utils crm dash misearch
multi-isearch texinfo texinfo-loaddefs tex-mode compare-w
make-mode css-mode smie sgml-mode facemenu imenu eww vtable
url-queue shr pixel-fill kinsoku url-file svg xml dom mm-url gnus
message sendmail yank-media puny rfc822 mml mml-sec epa epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
nnheader gnus-util mail-utils range mm-util mail-prsvr color
python skeleton cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-langs cc-vars cc-defs cc-bytecomp
c++-ts-mode c-ts-mode c-ts-common mule-util dired-aux dired-x
dired dired-loaddefs lua-ts-mode treesit flymake server warnings
tabify fennel-mode xref project inf-lisp shell pcomplete shortdoc
help-fns radix-tree cl-print debug backtrace find-func apropos
cursor-sensor compile text-property-search comint ansi-osc
ansi-color comp-run comp-common smerge-mode diff disp-table
whitespace emacs-news-mode time-date vc-git diff-mode
track-changes derived files-x vc-dir ewoc vc vc-dispatcher
bug-reference completion-preview easy-mmode pcase noutline outline
ruler-mode specter-theme auth-source-pass winner ring savehist
repeat midnight visual-wrap paren-face compat goto-addr thingatpt
cl-extra help-mode autorevert filenotify elec-pair completion
desktop frameset delsel autoinsert cus-start time init
fennel-mode-autoloads magit-autoloads git-commit-autoloads
dash-autoloads magit-section-autoloads paren-face-autoloads
finder-inf info with-editor-autoloads xr-autoloads package
browse-url xdg url url-proxy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json map byte-opt gv bytecomp byte-compile
url-privacy url-vars early-init rx subr-x cus-edit pp cus-load
icons wid-edit cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
touch-screen pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer
select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face
macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk
pgtk multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)

Memory information:
((conses 16 4219242 387989) (symbols 48 31297 4)
 (strings 32 279165 15056) (string-bytes 1 12853103)
 (vectors 16 57830) (vector-slots 8 656011 595942) (floats 8 646 3216)
 (intervals 56 848446 3470) (buffers 992 79))

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

john muhl <jm@pub.pink> writes:

> user-init-file is trusted by default but not other user files.
>
>   C-xf ~/.emacs.d/early-init.el
>   M-x flymake-mode
>
> Produces a warning:
>
>   Disabling elisp-flymake-byte-compile in early-init.el (untrusted content)
>
> custom-file (when not the same as user-init-file) also causes a
> warning. Should these also be trusted by default?
>
> What about files put in place by a system admin or your distro’s
> Emacs package (e.g. site-run-file, default.el)? They generally
> require root priviledges to install so if they can’t be trusted
> you’re already in trouble.

Makes sense to me.

Maybe we should install something like the below?

diff --git a/lisp/files.el b/lisp/files.el
index c92fc0608dd..293f3c59c0d 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -748,10 +748,16 @@ trusted-content-p
          (with-demoted-errors "trusted-content-p: %S"
            (let ((exists (file-exists-p buffer-file-truename)))
              (or
-              ;; We can't avoid trusting the user's init file.
-              (if (and exists user-init-file)
-                  (file-equal-p buffer-file-truename user-init-file)
-                (equal buffer-file-truename user-init-file))
+              ;; We can't avoid trusting the user's init file, etc.
+              (memq t
+                    (mapcar
+                     (lambda (file)
+                       (if (and exists file)
+                           (file-equal-p buffer-file-truename file)
+                         (equal buffer-file-truename file)))
+                     (list user-init-file
+                           early-init-file
+                           site-run-file)))
               (let ((file (abbreviate-file-name buffer-file-truename))
                     (trusted nil))
                 (dolist (tf trusted-content)

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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.


        Stefan

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
>  <eliz@gnu.org>,  Andrea Corallo <acorallo@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.

More generally, if we go this way, i.e. every complaint by some user
about a file that _could_ be trusted, or even is trusted on a group of
systems, causes us to add more and more files and directories to the
trusted list, there will be no end to this, and, significantly, Emacs
30 will never be released.

So from where I stand, what we have now on the latest emacs-30 branch
is as good and as far as it gets, at least for Emacs 30.  My
suggestion to anyone who wants additional files/directories to vet to
please use the existing facilities to add them to the trusted list.
This way, we collect experience and data points regarding which
files/directories and under what conditions should be trusted, and can
improve what we have now in the future.  At that future time we should
probably ask users to name the files and directories they needed to
add to the trusted list, and take it from there, making changes which
will take that into account.

If you still insist on installing such changes at this time, please do
that on master.  My preference is to wait with this until we have
enough experience with what we have, which means not before Emacs 30.1
is released and a couple of months go by.  But if people insist on
installing now on master, I won't object.

Thanks.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
>>  <eliz@gnu.org>,  Andrea Corallo <acorallo@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`.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 22 Dec 2024 17:36:15 +0000
> Cc: jm@pub.pink, 75017@debbugs.gnu.org, acorallo@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
> >>  <eliz@gnu.org>,  Andrea Corallo <acorallo@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.  So if such a file somehow materializes
there, I want to know, pronto.

bug#75017: 31.0.50; Untrusted user lisp files

[Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors]

(Apologies for not following this thread.)

If this is about Emacs claiming/suggesting
that something is trusted or untrusted, I'd
say we're better off saying only that Emacs
CANNOT vouch for the thing to be trusted.

That's better than claiming that something
can't be trusted.  And it's _much_ better
than claiming that something _can_ be trusted.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sun, 22 Dec 2024 17:36:15 +0000
>> Cc: jm@pub.pink, 75017@debbugs.gnu.org, acorallo@gnu.org
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> >> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
>> >>  <eliz@gnu.org>,  Andrea Corallo <acorallo@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.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 23 Dec 2024 14:10:30 +0000
> Cc: monnier@iro.umontreal.ca, jm@pub.pink, 75017@debbugs.gnu.org, 
> 	acorallo@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

I think this is over-engineering.  Yes, there are situations where it
makes sense to trust site-init-file.  No, they are not 100% of the
possible situations.  Which in my book means we should leave it to
users to decide whether to trust that file or not.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I think this is over-engineering.  Yes, there are situations where it
> makes sense to trust site-init-file.  No, they are not 100% of the
> possible situations.  Which in my book means we should leave it to
> users to decide whether to trust that file or not.

How do you feel about early-init-file?

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 24 Dec 2024 00:35:10 +0000
> Cc: monnier@iro.umontreal.ca, jm@pub.pink, 75017@debbugs.gnu.org, 
> 	acorallo@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think this is over-engineering.  Yes, there are situations where it
> > makes sense to trust site-init-file.  No, they are not 100% of the
> > possible situations.  Which in my book means we should leave it to
> > users to decide whether to trust that file or not.
> 
> How do you feel about early-init-file?

I'm with Stefan Monnier on this one: there's no urgency to make any
changes in that area.

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Stefan Kangas <stefankangas@gmail.com>
>>> Date: Sun, 22 Dec 2024 17:36:15 +0000
>>> Cc: jm@pub.pink, 75017@debbugs.gnu.org, acorallo@gnu.org
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
>>> >> Cc: john muhl <jm@pub.pink>,  75017@debbugs.gnu.org,  Eli Zaretskii
>>> >>  <eliz@gnu.org>,  Andrea Corallo <acorallo@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.)


How does it make sense to not trust site-run-file when we trust the
site-lisp?
Further it is very likely or on Unix systems almost always the case that
Emacs was built by those who control the site-run-file. How is it
possible to trust them on the Emacs binary or anything elese included in
the Emacs package but not site-run-file?

>
> 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.

Also by that point the attacker could already manipulate other files
such as the Emacs binary itself.

> 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.

What about checking if the location of site-run-file machtes with the
location of the fiel during compilation e.g. by taking the value from
the pdump or configuring the check value into the executable without
pdump if that is better?

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: john muhl <jm@pub.pink>
> Date: Sat, 21 Dec 2024 14:48:52 -0600
> 
> user-init-file is trusted by default but not other user files.
> 
>   C-xf ~/.emacs.d/early-init.el
>   M-x flymake-mode
> 
> Produces a warning:
> 
>   Disabling elisp-flymake-byte-compile in early-init.el (untrusted content)
> 
> custom-file (when not the same as user-init-file) also causes a
> warning. Should these also be trusted by default?

No, not IMO.  Please add those files you know you can trust to the
list of trusted files, and let's see if that works well for you.  If,
after you have used that for some time, you have observations to
report or changes to suggest, please do, but let's please base such
observations on some sufficiently significant (read: long enough)
experience.

> What about files put in place by a system admin or your distro’s
> Emacs package (e.g. site-run-file, default.el)? They generally
> require root priviledges to install so if they can’t be trusted
> you’re already in trouble.

On my system, these files do not need any admin privileges, so I don't
think we should trust them by default.  Users who know that these
files are modified only by trusted admins can and probably should add
them to the list of trusted files, if they need that (in general,
there should be no need to run Flymake in those files, in which case
these files don't need to be added even if they are trusted).

Btw, if we are talking about trusted admins, then entire directories
should be trusted, for example /usr/share or /usr/share/emacs.
There's a reason why we didn't do that by default.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: john muhl <jm@pub.pink>
>> Date: Sat, 21 Dec 2024 14:48:52 -0600
>>
>> user-init-file is trusted by default but not other user files.
>>
>>   C-xf ~/.emacs.d/early-init.el
>>   M-x flymake-mode
>>
>> Produces a warning:
>>
>>   Disabling elisp-flymake-byte-compile in early-init.el (untrusted content)
>>
>> custom-file (when not the same as user-init-file) also causes a
>> warning. Should these also be trusted by default?
>
> No, not IMO.  Please add those files you know you can trust to the
> list of trusted files, and let's see if that works well for you.  If,
> after you have used that for some time, you have observations to
> report or changes to suggest, please do, but let's please base such
> observations on some sufficiently significant (read: long enough)
> experience.
>
>> What about files put in place by a system admin or your distro’s
>> Emacs package (e.g. site-run-file, default.el)? They generally
>> require root priviledges to install so if they can’t be trusted
>> you’re already in trouble.
>
> On my system, these files do not need any admin privileges, so I don't
> think we should trust them by default.  Users who know that these
> files are modified only by trusted admins can and probably should add
> them to the list of trusted files, if they need that (in general,
> there should be no need to run Flymake in those files, in which case
> these files don't need to be added even if they are trusted).

I don't think it's meaningful to consider them as not
`trusted-content-p`, when we automatically load these files into any
running Emacs session.

> Btw, if we are talking about trusted admins, then entire directories
> should be trusted, for example /usr/share or /usr/share/emacs.

Yes, though we'd have to discuss which directories those are;
`load-path` and `source-directory` are two candidates.

> There's a reason why we didn't do that by default.

My understanding is that we just didn't consider all of these cases.
At least I didn't.

If others did, it wasn't sufficiently explicit for me to notice.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 22 Dec 2024 17:20:13 +0000
> Cc: 75017@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, not IMO.  Please add those files you know you can trust to the
> > list of trusted files, and let's see if that works well for you.  If,
> > after you have used that for some time, you have observations to
> > report or changes to suggest, please do, but let's please base such
> > observations on some sufficiently significant (read: long enough)
> > experience.
> >
> >> What about files put in place by a system admin or your distro’s
> >> Emacs package (e.g. site-run-file, default.el)? They generally
> >> require root priviledges to install so if they can’t be trusted
> >> you’re already in trouble.
> >
> > On my system, these files do not need any admin privileges, so I don't
> > think we should trust them by default.  Users who know that these
> > files are modified only by trusted admins can and probably should add
> > them to the list of trusted files, if they need that (in general,
> > there should be no need to run Flymake in those files, in which case
> > these files don't need to be added even if they are trusted).
> 
> I don't think it's meaningful to consider them as not
> `trusted-content-p`, when we automatically load these files into any
> running Emacs session.

No, we don't load anything.  It's the user who tells us whether to
load these files, by placing them in those locations and naming them
according to what Emacs looks for.  It's up to the user to tell us
whether everything in those files is trustworthy.

And let's not forget that various packages write to the init files, so
not everything there was written by the user.

bug#75017: 31.0.50; Untrusted user lisp files

[Dmitry Gutov]

On 22/12/2024 20:38, Eli Zaretskii wrote:
> And let's not forget that various packages write to the init files, so
> not everything there was written by the user.

And Emacs will load whatever's written there on the next restart. 
Whether the user wrote to those files, or someone else.

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> Date: Sun, 22 Dec 2024 21:52:28 +0200
> Cc: jm@pub.pink, 75017@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 22/12/2024 20:38, Eli Zaretskii wrote:
> > And let's not forget that various packages write to the init files, so
> > not everything there was written by the user.
> 
> 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..?

bug#75017: 31.0.50; Untrusted user lisp files

[Dmitry Gutov]

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.

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.

bug#75017: 31.0.50; Untrusted user lisp files

[Dmitry Gutov]

On 23/12/2024 14:31, 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.
> 
> IMO, we should only make files and directories trusted by default if
> we are either 100% sure they can never be malicious

Thank you. So the scenario where we would make the distinction is when 
the user managed to notice (somehow?) that the file had changed during 
the Emacs session, and then went to edit it.

To be frank, I asked the question after reading the scenario from the 
first message, and it talks about early-init-file. IIUC this file lives 
in the same dir as the plain user-init-file, so the chances of them 
being edited by someone other than the user should be about equal, and 
we do "trust" the latter file automatically.

Probably not too critical, but inconsistencies can be annoying (the user 
has to spend time figuring out whether something is broken and why).

bug#75017: 31.0.50; Untrusted user lisp files

[Sean Whitton]

Hello,

On Wed 25 Dec 2024 at 01:29am +02, Dmitry Gutov wrote:

> Thank you. So the scenario where we would make the distinction is when the
> user managed to notice (somehow?) that the file had changed during the Emacs
> session, and then went to edit it.
>
> To be frank, I asked the question after reading the scenario from the first
> message, and it talks about early-init-file. IIUC this file lives in the same
> dir as the plain user-init-file, so the chances of them being edited by
> someone other than the user should be about equal, and we do "trust" the
> latter file automatically.
>
> Probably not too critical, but inconsistencies can be annoying (the user has
> to spend time figuring out whether something is broken and why).

For Debian we'll probably patch in so everything that we install on the
system is automatically trusted.  It seems natural to me to see this as
the distributor's responsibility.

-- 
Sean Whitton

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Eli Zaretskii <eliz@gnu.org>,  jm@pub.pink,  stefankangas@gmail.com,
>   75017@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 07:39:16 +0000
> 
> For Debian we'll probably patch in so everything that we install on the
> system is automatically trusted.  It seems natural to me to see this as
> the distributor's responsibility.

I think this is the end-user's responsibility, not yours.  So I urge
you to reconsider.  At the very least ask the user at installation
time whether she wants to declare the entire tree trusted, but don't
do it unconditionally, because it basically renders this change in
large part ineffective, and then why did we even bother to do it,
delaying the release etc.?

bug#75017: 31.0.50; Untrusted user lisp files

[Sean Whitton]

Hello,

On Fri 27 Dec 2024 at 10:35am +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  jm@pub.pink,  stefankangas@gmail.com,
>>   75017@debbugs.gnu.org
>> Date: Fri, 27 Dec 2024 07:39:16 +0000
>>
>> For Debian we'll probably patch in so everything that we install on the
>> system is automatically trusted.  It seems natural to me to see this as
>> the distributor's responsibility.
>
> I think this is the end-user's responsibility, not yours.  So I urge
> you to reconsider.  At the very least ask the user at installation
> time whether she wants to declare the entire tree trusted, but don't
> do it unconditionally, because it basically renders this change in
> large part ineffective, and then why did we even bother to do it,
> delaying the release etc.?

It sounds like I am significantly misunderstanding something.  I thought
that this trusted-files change was about, e.g., random Lisp files in my
~/Downloads/.  Debian will certainly not be marking those as trusted!

Let me step back a bit.

If you install Emacs on the next release of Debian and you enable
installing all suggested packages, you'll also get a bunch of major
modes from GNU ELPA and elsewhere, such as markdown-mode (thanks to
Xiyue Deng for sorting out the metadata such that these other modes are
suggested by our package manager).

These are Debian-vetted versions of these packages; we have lots of
users who don't want to use package.el directly.  The Lisp is installed
under /usr/share/emacs/site-lisp/elpa-src.  It's equally as safe as the
code for Emacs itself; the same people (Debian Developers) have upload
access for Emacs and for all those other major modes.  So, I would have
thought we would be marking those as trusted on behalf of our users.

Does this still seem wrong to you?  Can you see what I've misunderstood?

-- 
Sean Whitton

bug#75017: 31.0.50; Untrusted user lisp files

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: dmitry@gutov.dev,  jm@pub.pink,  stefankangas@gmail.com,
>   75017@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 13:36:55 +0000
> 
> > I think this is the end-user's responsibility, not yours.  So I urge
> > you to reconsider.  At the very least ask the user at installation
> > time whether she wants to declare the entire tree trusted, but don't
> > do it unconditionally, because it basically renders this change in
> > large part ineffective, and then why did we even bother to do it,
> > delaying the release etc.?
> 
> It sounds like I am significantly misunderstanding something.  I thought
> that this trusted-files change was about, e.g., random Lisp files in my
> ~/Downloads/.  Debian will certainly not be marking those as trusted!

Right.

> Let me step back a bit.
> 
> If you install Emacs on the next release of Debian and you enable
> installing all suggested packages, you'll also get a bunch of major
> modes from GNU ELPA and elsewhere, such as markdown-mode (thanks to
> Xiyue Deng for sorting out the metadata such that these other modes are
> suggested by our package manager).
> 
> These are Debian-vetted versions of these packages; we have lots of
> users who don't want to use package.el directly.  The Lisp is installed
> under /usr/share/emacs/site-lisp/elpa-src.  It's equally as safe as the
> code for Emacs itself; the same people (Debian Developers) have upload
> access for Emacs and for all those other major modes.  So, I would have
> thought we would be marking those as trusted on behalf of our users.
> 
> Does this still seem wrong to you?  Can you see what I've misunderstood?

I think you assume that since this stuff is installed from Debian,
those directories are forever trusted.  But that is only true
immediately after the installation.  Some time after that, anything
can happen with these directories.  Whether they can be trusted from
now to eternity is something for the user to say.

At least this is my opinion.  I don't see myself as an expert on this,
so please wait for Stefan and others to chime in if they have
different opinions.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> For Debian we'll probably patch in so everything that we install on
> the system is automatically trusted.

Sounds fine, yes.

> It seems natural to me to see this as the
> distributor's responsibility.

Agreed.  Anything that we know has been installed consciously by the
sysadmin should be trustworthy because we don't really get to choose not
to trust the sysadmin,


        Stefan

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> For Debian we'll probably patch in so everything that we install on
>> the system is automatically trusted.
>
> Sounds fine, yes.

IMHO this probably applies to all distributions.

Is site-lisp not trusted by default when launching with
site-lisp/site-init enabled?

bug#75017: 31.0.50; Untrusted user lisp files

[john muhl]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: john muhl <jm@pub.pink>
>> Date: Sat, 21 Dec 2024 14:48:52 -0600
>> 
>> user-init-file is trusted by default but not other user files.
>> 
>>   C-xf ~/.emacs.d/early-init.el
>>   M-x flymake-mode
>> 
>> Produces a warning:
>> 
>>   Disabling elisp-flymake-byte-compile in early-init.el (untrusted content)
>> 
>> custom-file (when not the same as user-init-file) also causes a
>> warning. Should these also be trusted by default?
>
> No, not IMO.  Please add those files you know you can trust to the
> list of trusted files, and let's see if that works well for you.  If,
> after you have used that for some time, you have observations to
> report or changes to suggest, please do, but let's please base such
> observations on some sufficiently significant (read: long enough)
> experience.

Sure. That’s what I’ve done and it’ll certainly work for me. I
very rarely need to deal with untrusted files so of all Emacs
users I’ll be among those affected the least.

>> What about files put in place by a system admin or your distro’s
>> Emacs package (e.g. site-run-file, default.el)? They generally
>> require root priviledges to install so if they can’t be trusted
>> you’re already in trouble.
>
> On my system, these files do not need any admin privileges, so I don't
> think we should trust them by default.  Users who know that these
> files are modified only by trusted admins can and probably should add
> them to the list of trusted files, if they need that (in general,
> there should be no need to run Flymake in those files, in which case
> these files don't need to be added even if they are trusted).
>
> Btw, if we are talking about trusted admins, then entire directories
> should be trusted, for example /usr/share or /usr/share/emacs.
> There's a reason why we didn't do that by default.

Makes sense. These system files were a bit of a tangent to what
triggered this issue.

Specifically, I was surprised to find that user-init-file is
assumed safe but not early-init-file. After reading the
trusted-content part of the manual where it says “…which means no
file is trusted.” I assumed that included user-init-file. When I
saw that wasn’t the case I then assumed early-init-file would get
the same treatment. Maybe a little extra clarity there would be
sufficient for now.

bug#75017: 31.0.50; Untrusted user lisp files

[john muhl]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: john muhl <jm@pub.pink>
>> Cc: 75017@debbugs.gnu.org
>> Date: Sun, 22 Dec 2024 18:32:00 -0600
>> 
>> Specifically, I was surprised to find that user-init-file is
>> assumed safe but not early-init-file. After reading the
>> trusted-content part of the manual where it says “…which means no
>> file is trusted.” I assumed that included user-init-file. When I
>> saw that wasn’t the case I then assumed early-init-file would get
>> the same treatment. Maybe a little extra clarity there would be
>> sufficient for now.
>
> Maybe we should trust the early-init-file as well, but then where does
> this end?  The init files can load gobs of other files.  And there's
> also custom-file (when it isn't nil), desktop-dirname and
> desktop-base-file-name, etc. etc.

For Emacs 30 I’d end it with user-init-file, early-init-file and
custom-file. The latter is already an implicit part of trusting of
the user-init-file so it shouldn’t add any additional risk. The
former two are I think in the same category of presumed safeness
so distinguishing one as trusted and the other not seems odd.

Longer term I agree with you that more experience will lead to
better understanding of where to draw the line.

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Maybe we should trust the early-init-file as well, but then where does
> this end?  The init files can load gobs of other files.  And there's
> also custom-file (when it isn't nil), desktop-dirname and
> desktop-base-file-name, etc. etc.
> Stefan, WDYT about this?

For Emacs-30, I see no need to make changes to what we have in this
regard for the simple reason that `elisp-flymake-byte-compile` usually
doesn't give great feedback in init files or in most of those other
funny loaded files like desktop's (both false positives and false
negatives).  So there's no hurry in deciding whether to include
`early-init-file`, or `custom-file`, or `desktop-dirname`, or ...

More useful might be to auto-trust the packages's ELisp files
found in `load-path` (because these are files for which that backend
should usually give good quality feedback). But that's a bigger change
and it's not completely clear which files we should trust there, so
I don't think we're ready to add that in `emacs-30`.


        Stefan

bug#75017: 31.0.50; Untrusted user lisp files

[Stefan Kangas]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> Maybe we should trust the early-init-file as well, but then where does
>> this end?  The init files can load gobs of other files.  And there's
>> also custom-file (when it isn't nil), desktop-dirname and
>> desktop-base-file-name, etc. etc.
>> Stefan, WDYT about this?
>
> For Emacs-30, I see no need to make changes to what we have in this
> regard for the simple reason that `elisp-flymake-byte-compile` usually
> doesn't give great feedback in init files or in most of those other
> funny loaded files like desktop's (both false positives and false
> negatives).  So there's no hurry in deciding whether to include
> `early-init-file`, or `custom-file`, or `desktop-dirname`, or ...
>
> More useful might be to auto-trust the packages's ELisp files
> found in `load-path` (because these are files for which that backend
> should usually give good quality feedback). But that's a bigger change
> and it's not completely clear which files we should trust there, so
> I don't think we're ready to add that in `emacs-30`.

I agree that what we have is fine for Emacs 30.