unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Unsafe file variables...
Date: 04 Apr 2004 22:28:15 +0200	[thread overview]
Message-ID: <x5r7v3bi8w.fsf@lola.goethe.zz> (raw)
In-Reply-To: <87y8pbh5lk.fsf-monnier+emacs@alfajor.local>

Stefan Monnier <monnier@iro.umontreal.ca> 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

  reply	other threads:[~2004-04-04 20:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-03 19:06 Unsafe file variables David Kastrup
2004-04-04 16:25 ` Richard Stallman
2004-04-04 20:04   ` Stefan Monnier
2004-04-04 20:11   ` Stefan Monnier
2004-04-04 20:28     ` David Kastrup [this message]
2004-04-04 20:49       ` Stefan Monnier
2004-04-05  2:14         ` David Kastrup
2004-04-05  3:13           ` Stefan Monnier
2004-04-05 10:34             ` David Kastrup
2004-04-05  6:36     ` Richard Stallman
2004-04-05 11:56       ` Kim F. Storm
2004-04-05 12:06       ` Kim F. Storm
2004-04-07  0:09         ` Richard Stallman
2004-04-07 17:37           ` Kevin Rodgers
2004-04-05  0:44 ` Kim F. Storm
2004-04-05  2:25   ` Kim F. Storm
2004-04-05  9:08     ` Eli Zaretskii
2004-04-05 12:08       ` Kim F. Storm

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=x5r7v3bi8w.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /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).