Running SSharp in a sandboxed AppDomain

63 views
Skip to first unread message

mla...@gmail.com

unread,
Aug 9, 2013, 8:08:17 PM8/9/13
to ssh...@googlegroups.com
Hello,

I've tried to embed the latest version of SSharp (from github) in my application to run scripts in a sandboxed AppDomain. It is essential for the entire SSharp assembly to be security transparent, so that scripts (they are untrusted) executed cannot randomly delete files on my computer. However, there are 3 places in SSharp access security critical code which requires elevated permissions:

1. The last method of MethodBinding.cs (https://github.com/PetroProtsyk/SSharp/blob/master/SSharp.Net/Runtime/Promotion/MethodBinding.cs)
2. The last method of DelayedMethodBinding.cs (https://github.com/PetroProtsyk/SSharp/blob/master/SSharp.Net/Runtime/Promotion/DelayedMethodBinding.cs)
3. The Initialize() and Dispose() methods of AssemblyManager (https://github.com/PetroProtsyk/SSharp/blob/master/SSharp.Net/Runtime/AssemblyManager.cs)

In cases 1 and 2, the security critical method accessed is
return invokableMethod.Target.GetType().GetMethod(invokableMethod.MethodName).MethodHandle.GetFunctionPointer();
More specifically the GetFunctionPointer() part.

In case 3, the security critical methods accessed is

AppDomain.CurrentDomain.AssemblyLoad += CurrentDomainAssemblyLoad;
AppDomain.CurrentDomain.AssemblyLoad -= CurrentDomainAssemblyLoad;


I'm not worried about case 3 because I use BaseAssemblyManager instead to control which types are available to scripts. But I *do* worry about cases 1 and 2.
So here is my question:

What does the
public static implicit operator IntPtr(DelayedMethodBinding invokableMethod)
method do in cases 1 and 2 above? Because I've commented out the methods and everything still compiles and seems to work correctly. Is it safe to remove those methods
and still retain all (or most) features of SSharp?

Thanks,
Regards,
Lawrence.






Petro Protsyk

unread,
Aug 12, 2013, 3:39:04 PM8/12/13
to ssh...@googlegroups.com
Hello Lawrence,

 These two cases (1) and (2) are used in specific scenario for creating delegates from functions defined in the script. See for example test called "Threading". In this test, the thread will execute ThreadTest function defined in the script. To my knowledge this should be by far the only usage of these methods.

 If you are not planning to use this feature you can remove that code.

Regards,
 Petro


2013/8/10 <mla...@gmail.com>

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

piter....@gmail.com

unread,
Aug 12, 2013, 3:50:48 PM8/12/13
to ssh...@googlegroups.com
Please note, I have decided to reconsider the need for these two methods you have mentioned. There is a registered issue: https://github.com/PetroProtsyk/SSharp/issues/32

mla...@gmail.com

unread,
Aug 12, 2013, 8:30:07 PM8/12/13
to ssh...@googlegroups.com
Hi Petro,

Thanks for the explanation. I don't think having method delegates in scripts is that important for me, so I will just comment out those 2 methods. In any case, I think I can work around the lack of delegates through IInvokable callbacks (similar to what Java does with the Listener interfaces).

Cheers,
Lawrence.
Reply all
Reply to author
Forward
0 new messages