Script Protection Idea

[SirWobbyTheFirst]

Oh it's fine Richard, I would try implementing something myself and I think I could probably try doing some C++ again given that last time I did C++ was when I was starting out in 03 and didn't have any programming knowledge whatsoever. Now it's different because I've worked in LC, Visual Basic, C# and Java and have a general knowledge of how they all work together, but I don't know where to start in terms of the source code files for introducing a property and then implementing the functionality.

If I did, I would have been working on it now and when finished, could have submitted it for review by Mark and the team.

[FourthWorld]

... I don't know where to start in terms of the source code files for introducing a property and then implementing the functionality.

If I did, I would have been working on it now and when finished, could have submitted it for review by Mark and the team.

You and I are in the same boat, but at least we're in good company: RunRev themselves will often explore scripted solutions first, since of course the scripting language is said to be powerful and easy to use.

If this can be done in the engine even better, but for anyone with an immediate need I'll bet a suitable means of protection from malware can be achieved with reasonable effort.

[SirWobbyTheFirst]

Oh by all means, I'm fine to wait for the time being and for the moment I'm utilizing MD5 hashes on files and I personally doubt any of my projects will be started until the new engine comes out in September what with YouTube stuff and all. But I figured it was a good idea given that the script protection did have a good use in terms of security of your script. I had a user complain that my app white screened with a "App has stopped working" dialog in Windows and sure enough, they described what they we're doing and I tried to recreate the bug but to no avail.

I asked what kind of plugins they had running and I grabbed the same plugins, setup a separate profile for the EXE and sure enough one of the plugins was clearing my stack script and so I decided to encrypt the stack but keep the source code open and it stopped that plugin from essentially generating useless error reports for Microsoft and headaches for me. So I figured it would be a cool thing to implement.

Although it would probably be best for the engine revamp as we can expect that to break compatibility with existing software. I hope to god this makes sense.

[FourthWorld]

Makes good sense to me. Sounds like a good plan for both now and the future.

[SirWobbyTheFirst]

Thank you very much good sir.

[monte]

Monte, if you are up for a little collaboration project, I could help implement some code to do something like this, my C++ skills aren't really existent but I could add to the IDE functionality and then if Markie boy says its good, it could be implemented into the mainstream IDE.

Just read this. I think it would be good to wait for Mark to architect a solution on this one but in essence I don't think it would be all that complicated to add a flag to the stack editScripts that was ifdefed in the setprop method for MODE_DEVELOPMENT. So in the IDE you could set it all you like but in the standalone you can't change it.

I haven't yet looked at what's involved with adding a new flag to an object and getting the engine to save it but the rest of this is relatively simple. I'm wondering if the functionality could actually be hung off cantModify which would save this bit. Perhaps cantDelete and cantAbort should also be immutable in standalones... If it were hung off cantModify I'd say the least interruption to current workflows would be to allow script edits if cantModify is true in the IDE but in standalone disallow them. Still... I know the language police will send their henchmen after me for suggesting a change in the behavior of an existing property...

[SirWobbyTheFirst]

Well like I mentioned to Rich (I just used a nickname, bromance inbound ) this thing would probably be suited for the engine revamp now that I think about it, the engine revamp, we can be pretty sure its going to break compatibility with existing software and I think in that sense, 6.0+ would probably be better suited for being feature frozen and the feature stuff being placed in the IDE/Engine when the revamp occurs.

I still think this is good food for thought.

[monte]

I think in the long run sandboxing stacks/groups of stacks together is a broader issue that might need some fundamental changes to the engine but a short term solution should be possible... BTW to have the security you want I think you would also need to block frontscripts and setting behaviours. Particularly now that we have before/after handlers for behaviors. There's lots to consider...

[SirWobbyTheFirst]

That is very true, we'll just have to see what happens I guess. Maybes the team might surprise us with something.

[LCMark]

Full sand-boxing is certainly something that is a way off... However, I can see that the 'loss' of password-protection has (in this case at least) caused a certain level of protection of an app from plugins that might have existed before.

I guess my main reservation with adding something to essentially emulate a side-effect of password protected stacks is that it seems like a relatively small defense against anything else plugins can do (frontScripts, backScripts, deleting controls etc.) and so I wonder if it does actually offer much.

[monte]

I think your right. If someone had malicious intent they could completely mess up an app just by setting the behavior of a few objects.

[LCMark]

So, taking a step back from full sandboxing, what is the minimum level of protection an app in a standalone needs to allow its core functionality to not be affected too much by potentially untrusted third-party plugin stacks?

It would be (relatively) straight-forward (I think) to allow standalones to have stacks in two 'modes' (if you will) - one 'kernel' and one 'user'. The 'kernel' stacks would be those considered to be 'included in the standalone' (both embedded in the exe, and in a list set at standalone build time). The 'user' stacks would be any others. Various actions in the engine could then be checked based on this flag the rule being 'kernel' stacks can do whatever they like; 'user' stacks could only affect other 'user' stacks.

For example, if a script running in a user stack tries to delete an object in a kernel stack its denied; if a script running in a user stack tries to set the script of an object in a kernel stack its denied.

The only thing is that this scoping would only work for the script calling the command that might have the effect, a user stack would still be able to (and need to) send messages to a kernel stack; and if the latter performs these operations it wouldn't be denied. However, that just means the app needs to be scripted to guard against such things.

Some things that could be protected (off the top of my head):

• Kernel scripts and stacks would always go before user ones in the message path.
• User scripts can't set properties on objects in kernel stacks.
• User scripts can't delete / cut / or any other operation that mutates the control tree in some way on kernel stacks.

[monte]

Sounds like a plan... I guess there's global variable scope but considering they are rarely a good idea then people can design them out.

What about recursing through the stackfiles of the mainstack and it's stackfiles to end up with a list of files that should be kernel files.

What about prohibiting adding front scripts?

[trevordevore]

So, taking a step back from full sandboxing, what is the minimum level of protection an app in a standalone needs to allow its core functionality to not be affected too much by potentially untrusted third-party plugin stacks?

Even if you protect the user stack from altering the host application you still have the issue of the 3rd party stack deleting files on the computer. Unless you can disable file access for the "user" stack and not the "kernel" stack then any solution only works for apps that explicitly turn off file system access.

Is it worth adding in any temporary solutions if the largest security hole is kept wide open? I think the only solution (short of sandboxing) is to host the plugin in a separate engine that has filesystem access turned off and runs in a separate space. You then broker messages back and forth between the two standalones.

[LCMark]

Well, I think the motivation for the original request was to stop plugins breaking the application they are running within, rather than protecting someone's system from a rampaging plugin. I think these are two slightly different concerns.

That being said, if we go down the route of having the possibility of 'user' and 'kernel' space then (off the top of my head) I can't see a reason why you couldn't key the secure* features off of that too. (Obviously, it would be then up to the 'kernel' stacks to sanitize the input from plugins to ensure they weren't trying to use it to do bad stuff).