fixes allowed instances inheritance lookup

[amedeiros]

In the allowed instances it was no going up the super class chain. This was causing us much pain. We saw you were doing this for allowed_kinds and allowed_classes but not allowed_instances. Was this intentional ?

[tario]

I need to check this a little more, but I think the current implementation is OK (i am not sure, really) Allowed instances is to control permissions of specific objects, not classes... but, in the other hand, all objects has a separated singleton hidden class, so... I get the point.

But there is a bigger problem here, the entire privileges model (EVEN the current privileges model) is Wrong, because authorizing method names/classes/instances whatever (like the current logic allows us to do) is highly error prone. I need to rewrite this whole privileges part to match the premise:

• You allow the call on known code you trust, not methods or symbols or classes *

Sorry, I should break backward compatibility on this soon, but I will keep the mantainance branch for this version, maybe, on this version your PR is ok (I need to evaluate it)

[amedeiros]

Ok thank you! We rely pretty heavy on this gem as I have not been able to find an alternative for a ruby sandbox. We execute customer generated code so this comes in handy. I am hoping to have some time to poke around it some more myself and make more pull requests.

[tario]

If this is important to you, maybe I should warn you, this gem is not 100% done and it may contain flaws, be careful, If the security provided by this sandbox is important to you, I suggest you to try to break the security of sandbox, i.e. look for vulnerabilities, be critical to the code. And be extremly careful about privileges asignment since the privilege part is the most flawed (from design point of view)

[amedeiros]

So we run customer generated ruby code from the sandbox. Several engineers spent several days trying to break out of the sandbox with no luck. We have some other checks around the code as well, but so far my experience with the sandbox has been good.

[amedeiros]

I want to understand this library better. Are you inserting your own method calls into the ruby code by turning it into s expressions inserting a method call to check access to an object or constant ect then converting it back to ruby code and executing it?

[tario]

In short, Yes.

Shikashi depends on evalhook, evalhook provides the interface to run any ruby code and hooking all ruby method calls (what shikashi is doing here, is providing the check for sandbox restrictions and the DSL to define them, while evalhook is in charge of running the ruby code with hooks)

This is the point where shikashi and evalhook is connected: https://github.com/tario/shikashi/blob/master/lib/shikashi/sandbox.rb#L415

Evalhook uses partialruby (a "partially done" ruby interpreter) to run the ruby code, partialruby accepts tree pre processors to modify the code before running it, here is the connection evalhook-partialruby:

https://github.com/tario/evalhook/blob/master/lib/evalhook.rb#L71

Partialruby is written in 100% pure ruby, to run the ruby code as optimal as possible, it transpiles from ruby to ruby. The main remaining cost, is the transpile part, (in pure ruby, of course), this cost is mitigated by offering a "packet of compiled code" feature

If this info is useful for you, maybe I should add it to the readme Thanks for the interest!