emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unsafe file variables...


From: David Kastrup
Subject: Re: Unsafe file variables...
Date: 04 Apr 2004 22:28:15 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Stefan Monnier <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]