From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: The `risky-local-variable' blacklist Date: Mon, 30 Aug 2004 20:13:16 -0600 (MDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1093918425 3814 80.91.224.253 (31 Aug 2004 02:13:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 Aug 2004 02:13:45 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 31 04:13:34 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C1y9O-00026y-00 for ; Tue, 31 Aug 2004 04:13:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C1yEE-0002t0-LA for ged-emacs-devel@m.gmane.org; Mon, 30 Aug 2004 22:18:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C1yE7-0002rw-Ic for emacs-devel@gnu.org; Mon, 30 Aug 2004 22:18:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C1yE4-0002rJ-Kc for emacs-devel@gnu.org; Mon, 30 Aug 2004 22:18:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C1yE4-0002qr-GM for emacs-devel@gnu.org; Mon, 30 Aug 2004 22:18:24 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1C1y98-0006tC-Jb for emacs-devel@gnu.org; Mon, 30 Aug 2004 22:13:18 -0400 Original-Received: from mailrelay2.lanl.gov (localhost.localdomain [127.0.0.1]) by mailwasher-b.lanl.gov (8.12.10/8.12.10/(ccn-5)) with ESMTP id i7V2DG6U000738 for ; Mon, 30 Aug 2004 20:13:16 -0600 Original-Received: from x-mail.lanl.gov (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (8.12.10/8.12.10/(ccn-5)) with ESMTP id i7V2DGVU000368 for ; Mon, 30 Aug 2004 20:13:16 -0600 Original-Received: from x-mail.lanl.gov (localhost.localdomain [127.0.0.1]) by x-mail.lanl.gov (8.12.10/8.12.10/(ccn-5)) with ESMTP id i7V2DGu6029284 for ; Mon, 30 Aug 2004 20:13:16 -0600 Original-Received: from localhost (herring@localhost) by x-mail.lanl.gov (8.12.10/8.12.10/Submit) with ESMTP id i7V2DGkt029280 for ; Mon, 30 Aug 2004 20:13:16 -0600 X-Authentication-Warning: x-mail.lanl.gov: herring owned process doing -bs Original-To: emacs-devel@gnu.org X-Scanned-By: MIMEDefang 2.35 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26632 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26632 (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.