From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Unsafe file variables... Date: 04 Apr 2004 22:28:15 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87y8pbh5lk.fsf-monnier+emacs@alfajor.local> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081111025 5280 80.91.224.253 (4 Apr 2004 20:37:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Apr 2004 20:37:05 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Apr 04 22:36:58 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BAEMU-0007Dx-00 for ; Sun, 04 Apr 2004 22:36:58 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BAEMT-0001G2-00 for ; Sun, 04 Apr 2004 22:36:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BAEJL-0004d0-EL for emacs-devel@quimby.gnus.org; Sun, 04 Apr 2004 16:33:43 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BAEFD-0001B4-QC for emacs-devel@gnu.org; Sun, 04 Apr 2004 16:29:27 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BAEE8-0000Nn-Ld for emacs-devel@gnu.org; Sun, 04 Apr 2004 16:28:52 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BAEE7-0000ND-JI for emacs-devel@gnu.org; Sun, 04 Apr 2004 16:28:19 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BAEE0-000492-Pq; Sun, 04 Apr 2004 16:28:13 -0400 Original-To: Stefan Monnier In-Reply-To: <87y8pbh5lk.fsf-monnier+emacs@alfajor.local> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 60 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21245 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21245 Stefan Monnier writes: > > Something like that. I would then customize a variable that tells > > whose signatures I trust enough not to get the stupid question again > > and again. > > > Obviously, this also makes it possible for me to look at the local > > variable block once, decide that it is good enough for me, and sign > > it. > > > It looks good to me, but it would be good to get comments > > from security experts. > > I think that using authentication for such problems is the wrong > approach. We should check the safety of the code instead. That implies that only one approach was possible. I was not talking about discouraging checking for safety: signatures should only be a fallback when the safety is not possible to check. And of course the user will be free not to accept any signatures and will lose nothing over the current situation. > Think of it as "check whether a piece of code is signed" (the > Microsoft notion of security) vs "check that the code type checks" > (the Java notion of security). Well, we already have determined that the variable _is_ unsafe to set. But since there still is an imaginable reason for setting that variable, the user gets the question. If you think that you can rule out the desirability of not mechanically checkable code being run, then that is the obvious way to go. But I don't see any sandbox model for Elisp that would get us even half there. > Now in general it's clearly impossible to check any arbitrary piece > of elisp code and give a good answer. But a good solution was > proposed a while back here: add a customization variable that allows > the user to specify a list of safe code which he's willing to eval > in the future. The list would have to get added to for each change. In short, the user would have to manually judge the potential of the danger of such settings for each change, and record his decision. I was proposing a mechanism allowing delegation of such decisions to a verified source the user has declared trustworthy. This is less safe than a qualified judgment of the user for himself for every instance. _IF_ the user is capable of making a qualified judgment. If he has to depend on others for it, a way to let him make sure that he at least knows reliably _who_ he is trusting to might not be amiss. Again: I was not certain about how good or feasible this proposal is, and I am also not sure whether it would not better be solved as an integral part of some scheme dealing with more than local variables. I just noticed that I get frequently annoyed by such questions and was trying to come up with a comparatively safe way to avoid them. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum