There is probably another ticket for this which I can't find right now, but...
The jython scripts need to be tightened up so that clients can run them without fear of harm to their systems. This outlines what will be done.
- No imports mode. There should be a mode where scripts are run, but no imports (other than autoplot.py) will be done.
- File open needs to be replaced with one that checks for 'w'. Many scripts use this to create files, and perhaps a set of sandbox directories can be identified. (/tmp . and not /etc, etc.)
The script editor, which shows the scripts, now keeps track of scripts that have been reviewed by the scientist.
The symbol "java" was unintentionally imported via "import java.lang.Thread", which forced me to kludge in "java=1" in the set up jython script. This resulted in a very confusing error message (see "AttributeError" email 05/22/2015). This is corrected.
It's not clear to me if the server should allow imports. There was special code that would prevent imports, but I don't see how this command line is any different than the command line on the app. Simon is experimenting with using the server to import his codes.
Last edit: Jeremy Faden 2015-07-16
I've been looking at how to sandbox the Jython code thread.
David suggested a while that the script only be shown once per download, rather than once per session. I think this is right, and it occurs to me that another aspect of security is simply knowing that things have changed, even if it was changed by a trusted party. I need to convince myself that HOME/autoplot_data/fscache is a trusted secure area, and scripts can always be run once they exist there.
I think between sandboxing the Jython thread and having a folder of known, okayed scripts to check against, this would be done.
Regarding David's suggestion that the review only happen once per download, I think the way to do this is to have a separate area for scripts which have been run already. Then running would check the web version (which might be downloaded using existing mechanisms) and suppress the warning if it is found in the separate area. Line 6178 of AutoplotUI is where "trust" is found.
I started experimenting with a separate "scripts" folder in autoplot_data which will store scripts which have been okayed. There's a differences engine I found which could be used to highlight the differences from the last run too. I need to find it.
I was looking at code where I'd experimented with the Java Sandbox. This looks like it's the way to get security, though I'd also like to explicitly restrict .jyds scripts automatically. To do this I'll have to figure out what they can do. For example, I'm sure that jyds scripts should not be able to:
but:
Last edit: Jeremy Faden 2020-12-18
The command line switch --sandbox and logger autoplot.security can be used to study how components access the system.
The property python.cachedir is a nice example of where Java code should be able to set the property, but Jython code should not. Presumably we would have a more restricted thread that is not able to set this.
Another set of more restrictive settings would be for server-side scripts, where the sandbox would exclude reads from outside of the AUTOPLOT_DATA area.
Future versions of Java drop security, so I don't think it's worth looking at this more.
Also I've added code which shows the difference between the current version and the last version run. This is good for security, but it is also useful to scientists wanting to verify they are getting a change.