From: Davis Herring <herring@lanl.gov>
Subject: The `risky-local-variable' blacklist
Date: Mon, 30 Aug 2004 20:13:16 -0600 (MDT) [thread overview]
Message-ID: <Pine.LNX.4.44.0408301850400.31548-100000@x-mail.lanl.gov> (raw)
(Apologies in advance for a long message, but this is a long issue.)
While looking at diffs for `timeclock.el', I noticed the addition of a
risk-local-variable declaration for "timeclock-mode-string". This is
certainly justified, but calls forth a bigger concern: is it wise to apply
a 'trust by default' policy when such innocuous-looking variables as that
mode-string can completely compromise a user's security (including
modifying configurations for further attacks)? Not to mention the threat
posed by Lisp authors (who possibly write popular packages not picked over
by the maintainers) that accidentally endanger their users (unless and
until the author (if needed) learns about risky variables, recognizes the
risk, and changes the code, and the users upgrade)...
The danger is especially pertinent since `enable-local-variables' defaults
to t and `normal-mode' overrides any paranoid setting of that variable
when called interactively or without its (optional!) argument.
It seems much safer in the long term to allow only specific variables to
be set by a local-variables specification, especially since relatively few
variables are useful to set that way. Of course, more things should be
possible with prompting, but such prompting should certainly (or at least
by default) be with `yes-or-no-p'.
Fortunately, this does not break existing code in notable ways, since the
`risky-local-variable' property would then be a no-op. At worst, the user
encounters prompts for files which did not previously cause them. This
may be a bit confusing, but if the files really are legitimate, that will
be evident at the time of the prompt.
Also, the protection versus honoring `eval' settings when root does little
good since it does not apply in other cases; anyone interested in rooting
via Emacs surely knows this.
Here is a list of local-variable settings used by the 21.3.1 lisp files:
calendar/calendar.el byte-compile-dynamic t
gnus/gnus-cite.el (coding) iso-latin-1
gnus/gnus-spec.el (coding) iso-latin-1
gnus/message.el (coding) iso-latin-1
gnus/nnultimate.el (coding) iso-latin-1
international/titdic-cnv.el (coding) (iso-2022-7bit)
play/landmark.el outline-layout (0 : -1 -1 0)
progmodes/ebrowse.el (eval) (useless)
tildify.el (coding) iso-latin-2
version.el version-control never
allout.el outline-layout (0 : -1 -1 0)
dired-x.el byte-compile-dynamic t
icomplete.el outline-layout (-2 :)
wid-edit.el byte-compile-dynamic t
(titdic-cnv.el is adding that coding specification into a buffer.)
We see a few codings (which are safe), a few `outline-layout's (safe), a
few `byte-compile-dynamic's (safe), a `version-control' (mostly safe; can
risk minor data loss), and one (eval) that does nothing but `put' safe
values on `lisp-indent-hook' properties. From this sample, there does not
appear to be much variety in (legitimate) local-variable settings; surely
anything truly useful in a file will be defined either globally or by the
mode for the file, and thus known and established by the time it is set.
Therefore, suggestions (all of them with some urgency):
* Drop `risky-local-variable' property: everything is risky unless
blessed as safe.
* Do not make `compile-command' safe; the default value for M-x compile is
of absolutely no use if one must first make sure that it has not in fact
become "rm -rf ~/*" since you started Emacs. Of course, the risk of
double-tapping RET after "M-x compile" is notable as well.
* Do not provide options for trusting non-"safe" variables (much less
eval) without prompting -- at the very least, force prompting for root!
* Prompt, when prompting is necessary, with `yes-or-no-p' unless the user
is not root and has asked for `y-or-n-p'.
* Provide a simple option to entirely prevent the setting or evaluation of
anything (except, say, mode and coding system) by a file, for use by the
paranoid. Make this be the default for root.
* In conjunction with the option for wholesale supression of this feature,
do not make `normal-mode' ignore these protections -- although with only
whitelisting and prompting, there is less for it to ignore.
* Fix the documentation of `enable-local-eval' so that it does not say
that `normal-mode' acts as if it were t (fortunately it does not).
* Rename (or at least re-document) `ignored-local-variables': it does not
ignore anything but merely causes "riskiness".
* Refine the check in `hack-one-local-variable' for harmless properties:
for instance, it appears to allow setting lisp-indent-hook to be a macro,
or to be bytecode. It would probably be better to have a safe-property
property for safe property symbols, handled as is safe-local-variable.
* Do not use `enable-local-eval' as a local flag to prevent dangerous bugs
in its handling; have `hack-one-local-variable' accept a flag FORCE which
overrides all protections, and have it return t if FORCE was set or if the
user accepted the risk when prompted. (This might be better done by
factoring the risk-checking and prompting out of
`hack-one-local-variable'.)
* (The doozy, of course:) Mark all safe local variables as such.
I would be happy to work on all these projects, but desire opinions (on
the whole issue and on the suggested changes) and suggestions before
undertaking such an endeavor.
Davis Herring
--
This product is sold by volume, not by mass. If it seems too dense or too
sparse, it means mass-energy conversion has occurred during shipping.
next reply other threads:[~2004-08-31 2:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-31 2:13 Davis Herring [this message]
2004-08-31 14:01 ` The `risky-local-variable' blacklist Stefan
2004-08-31 21:42 ` Davis Herring
2004-08-31 22:43 ` Stefan
2004-08-31 23:18 ` Davis Herring
2004-08-31 22:07 ` Richard Stallman
2004-08-31 23:07 ` Davis Herring
2004-09-01 19:24 ` Richard Stallman
2004-09-01 7:11 ` Kim F. Storm
2004-09-01 14:36 ` Stefan Monnier
2004-09-02 4:53 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.44.0408301850400.31548-100000@x-mail.lanl.gov \
--to=herring@lanl.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).