Leo must have another lock on the H-bomb

[Edward K. Ream]

It's sickening to contemplate .leo files that execute malicious scripts in @script nodes.  This is an existential threat to Leo's reputation.

Rev 6574 corrects a major security vulnerability: it prohibits setting @bool scripting-at-script-nodes = True in local (non-settings) files.

But this is not good enough.  Leo must require that an environment variable, say leo-startup-scripting, be True.  That will prevent any .leo file from enabling startup scripting all by itself.  I'll add this additional lock today.

Alas, malicious .leo files can still "deliver" malicious scripts in other ways, for example, by creating an @button node ("press me!") that runs a malicious script directly, or worse, sets leo-startup-scripting to True!

Edward

[Matt Wilkie]

A required environment variable to enable processing startup scripts seems like a reasonable precaution. And/or perhaps a command line option?

leo --autoexec=True  %home%\workbook.leo

would probably want to restrict to enabling it only for the file(s) named on the command line. Actually thinking about this more, I think a command line parameter is better than an environment var, easier to turn on and off for specific needs (and harder to forget that it's active).

-matt

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.

[Edward K. Ream]

On Wed, Jan 15, 2014 at 6:03 AM, Matt Wilkie <map...@gmail.com> wrote:

A required environment variable to enable processing startup scripts seems like a reasonable precaution. And/or perhaps a command line option?

leo --autoexec=True  %home%\workbook.leo

​Good idea.  But I think the more locks the better.  The environment variable *and* the command-line option.  What do you think?

Edward

[Jacob Peck]

I vote *just* for the command-line option.  Too many locks and the feature becomes useless, at which point why not just remove it completely?

I think there are valid usecases for @script nodes.  They are limited, but valid.  I don't think an environment variable is the way to go here -- that makes it *extremely* difficult for a user who mostly lives in Linux-land to get their .leo to work in Windows. (Familiarity and such -- it would take a good deal of googling for them to figure out the process.)

Additionally, such precautions don't prevent rogue plugins from enabling scripting anyways... all it would take is a `c.theScriptingController.atScriptNodes = True` followed by `c.theScriptingController.createAllButtons()` on their create hook to enable it and cause a bit of trouble...

In short, I don't think that there is *any* full solution to this problem.  But adding an env var *and* a command-line switch *and* a config setting is a bit much.  The only real risk I think is the setting *outside* of myLeoSettings.leo.

-->Jake

[Fidel N]

Totally agree with Jacob.

Also, stating the obvious, Leo should have a way for people to share files even if they are untrusted (I dream of finding one day a massive database of convenient Leo files and scripts, similar to http://code.activestate.com).

For this, perhaps Leo could offer some 'untrusted source' file opening, similar to what happens when you open an excel file with macros? Just to navigate the outline and perhaps basic functionality such as copy paste etc.

I mean, what is the point of creating good Leo outlines, if noone will trust you to open them? =)

[Fidel N]

I dont know if I actually made my point:

Im talking about some short of Leo file reader, just for navigating outlines, no scripting capabilities, so even if the scripts are on and they cleverly jump all security filters, they couldn't possibly work since the Leo version doesnt actually do scripts, would just be a reader.

[Edward K. Ream]

On Wednesday, January 15, 2014 6:39:44 AM UTC-6, Edward K. Ream wrote:

On Wed, Jan 15, 2014 at 6:03 AM, Matt Wilkie <map...@gmail.com> wrote:

A required environment variable to enable processing startup scripts seems like a reasonable precaution. And/or perhaps a command line option?

leo --autoexec=True  %home%\workbook.leo

​Good idea.  But I think the more locks the better.

On second thought, I agree with both Matt and Jacob.  The command-line option is best.  It is essentially bullet-proof--any script capable of spoofing this command-line option already has enough mojo to do anything.  Furthermore, a command-line option is the most explicit way of enabling scripting, and it will reduce irritating (overly verbose) warnings.

I'll do this asap, but I'm deep in the midst of the new @auto, and that comes before everything else.

EKR

[Jacob Peck]

> --
This loads Leo with no plugins:

python launchLeo.py --no-plugins

Scripting is a plugin, and Leo works fine without it.

-->Jake

[Jacob Peck]

Ignore that... Ctrl+B is in core, I think... but mod_scripting is where
the @script code lies, so without that the scripts won't run, regardless
of various ways of breaking the cage.

-->Jake

[Fidel N]

I have been thinking of a solution for this, what do you think about the following?

For Leo to open always the files in that mode by default:

python launchLeo.py --no-plugins

And show a button to make the file "editable" (Same as excel with macros option).

When that button is clicked Leo stores that file path in a path list, and from then on, its not asked before edition.

Resulting in Leo asking once per file (or per time you move the files from one computer to another) and people would be able to safely (and without special knowledege requirements) share files.

[Don Dwiggins]

How about "quarantining" scripts? I did a web search for "python
sandbox" and got several interesting hits.

--

Don Dwiggins
Advanced Publishing Technology

[Edward K. Ream]

On Wed, Jan 15, 2014 at 5:38 PM, Don Dwiggins <ddwi...@advpubtech.com> wrote:

How about "quarantining" scripts?  I did a web search for "python sandbox" and got several interesting hits.

Unless I am mistaken, Guido has given up on sandboxes.  A command-line options seems simpler and safer

EKR

[Don Dwiggins]

Thanks for the hint.  This led me to http://neopythonic.blogspot.com/2009/03/capabilities-for-python.html, in which GvR expresses his doubts, and some others weigh in on the issue.  (Also, some implicit questions are explored: what are we trying to defend against, and at what cost, and where do we place the defenses?)