Sandbox scripts

[oleg-shilo]

Moved from https://groups.google.com/forum/#!topic/cs-script/-rmb9329mv8

Hi,
first of all I would like to thank to developers. This is a great project!
I have been looking for examples how to create sandbox functionality for cs-scripts. I found this http://www.csscript.net/Samples/Sandbox.zip but this is pretty obsolete and since you not allow NetFx40_LegacySecurityPolicy it doesnt work.
Is there a code snippet for newer .NET?
Thank you very much!

[oleg-shilo]

The solution is as for normal (not scripted) execution. Except in your case you will be calling CSScript.Load(...). Below is a slight modification of the sandboxing sample:

var permSet = new PermissionSet(PermissionState.None);
permSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));

var newDomain = AppDomain.CurrentDomain.Clone("Sandbox", permSet, ...);
        
var sandboxer = (Sandboxer)Activator.CreateInstanceFrom(newDomain,
                                                        Assembly.GetExecutingAssembly().Location,
                                                        typeof(Sandboxer).FullName)
                                    .Unwrap();

sandboxer.ExecuteUntrusted();
...
public void ExecuteUntrusted()
{
    var script = CSScript.Load(scriptFile);
    . . .
}

[pavelkux]

Hi Oleg,
I tried what you suggested and created some kind of "wrapper" for CSScript.Load method like this:

`public class Sandboxer : MarshalByRefObject
{
static Sandboxer singleton = null;

    public static Sandboxer Singleton
    {
        get
        {
            if (singleton == null)
            {
                var permSet = new System.Security.PermissionSet(System.Security.Permissions.PermissionState.None);
                permSet.AddPermission(new System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityPermissionFlag.Execution));

                AppDomain newDomain = AppDomain.CurrentDomain.Clone("Sandbox", permSet);

                singleton = (Sandboxer)Activator.CreateInstanceFrom(newDomain,
                                                                        System.Reflection.Assembly.GetExecutingAssembly().Location,
                                                                        typeof(Sandboxer).FullName)
                                                    .Unwrap();     
            }
            return singleton;
        }
    }

    public static Assembly Load(string scriptFile, string assemblyFile, bool debugBuild, params string[] refAssemblies)
    {
        return Singleton.ExecuteUntrustedCode(scriptFile, assemblyFile, debugBuild, refAssemblies);        
    }


    public Assembly ExecuteUntrustedCode(string scriptFile, string assemblyFile, bool debugBuild, params string[] refAssemblies)
    {
        return CSScript.Load(scriptFile, assemblyFile, debugBuild, refAssemblies);
    }
}

`

but I get an exception:
Attempt by security transparent method 'CSScriptLibrary.CSScript.set_AssemblyResolvingEnabled(Boolean)' to access security critical method 'System.AppDomain.add_AssemblyResolve(System.ResolveEventHandler)' failed.\n\nAssembly 'CSScriptLibrary, Version=3.13.0.0, Culture=neutral, PublicKeyToken=null' is partially trusted, which causes the CLR to make it entirely security transparent regardless of any transparency annotations in the assembly itself. In order to access security critical code, this assembly must be fully trusted.

I am doing something wrong here?

[oleg-shilo]

The exception you are experiencing is a sandboxing exception. Exactly what you want to achieve.

You are trying to compile the script in the sandbox, which prohibits this kind of operations. If you even lift some of the sandbox restrictions you will still have to solve assembly probing problems. Too much headache...

Approach this task differently. Sandboxing has nothing to do with scripting. It is a canonical assembly loading challenge. Solve it without regard fir scripting. And when you are done just use CS-Script to build your assembly before executing it in the script.

This is the code that works:

static void Issue_126()
{
    var asm = CSScript.CompileCode(
                    @"using System;
                    public class Script
                    {
                        public static string SayHello(string greeting)
                        {
                            Console.WriteLine(greeting);
                            return greeting.ToUpper();
                        }
                    }");


    var gritting = Sandboxer.Singleton.Execute(File.ReadAllBytes(asm), 
                                                "Script", "SayHello", "Hello...");
}

public class Sandboxer : MarshalByRefObject
{
    static Sandboxer singleton = null;

    public static Sandboxer Singleton
    {
        get
        {
            if (singleton == null)
            {
                var permSet = new System.Security.PermissionSet(System.Security.Permissions.PermissionState.None);
                permSet.AddPermission(new System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityPermissionFlag.Execution));

                AppDomain newDomain = AppDomain.CurrentDomain.Clone("Sandbox", permSet);


                singleton = (Sandboxer)Activator.CreateInstanceFrom(newDomain,
                                                                    Assembly.GetExecutingAssembly().Location,
                                                                    typeof(Sandboxer).FullName).Unwrap();
            }
            return singleton;
        }
    }

    public object Execute(byte[] assemmbly, string type, string method, params object[] args)
    {
        return Assembly.Load(assemmbly)
                        .GetType(type)
                        .GetMethod(method)
                        .Invoke(null, args);
    }
}

[pavelkux]

Hi Oleg,
once again thank you very much for your reply.
I tried to follow your recommendation and this is what I wrote:

internal static class CSScriptLoader
    {
        public static Assembly Load(string scriptFile, string assemblyFile, bool debugBuild, params string[] refAssemblies)
        {
            string scriptFileContent = System.IO.File.ReadAllText(scriptFile);
            System.IO.Directory.CreateDirectory(CSScript.GetScriptTempDir());
            var asmInString = CSScript.CompileCode(scriptFileContent, refAssemblies);
            return Sandboxer.Singleton.Load(System.IO.File.ReadAllBytes(asmInString));
        }
    }
    internal class Sandboxer : MarshalByRefObject
    {
        static Sandboxer singleton = null;

        public static Sandboxer Singleton
        {
            get
            {
                if (singleton == null)
                {
                    var permSet = new System.Security.PermissionSet(System.Security.Permissions.PermissionState.None);
                    permSet.AddPermission(new System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityPermissionFlag.Execution));

                    AppDomain newDomain = AppDomain.CurrentDomain.Clone("Sandbox", permSet);

                    singleton = (Sandboxer)Activator.CreateInstanceFrom(newDomain,
                                                                            System.Reflection.Assembly.GetExecutingAssembly().Location,
                                                                            typeof(Sandboxer).FullName).Unwrap();     
                }
                return singleton;
            }
        }

        public Assembly Load(byte[] assemmbly)
        {
            return Assembly.Load(assemmbly);
        }        
    }

Three things to point out:

1. When I don't call System.IO.Directory.CreateDirectory(CSScript.GetScriptTempDir());, it crashes because of directory C:\Temp\CSSCRIPT doesnt exist. Shouldnt it create it automatically?
2. I changed the code you provided so I would "cache" the whole assembly (like I did from the CSScript.Load call). Is that ok?
3. Even when I run this code, it doesnt work. It crashes on this line Sandboxer.Singleton.Load(System.IO.File.ReadAllBytes(asmInString)); with exception
   _Exception thrown: 'System.IO.FileNotFoundException' in mscorlib.dll

Additional information: Could not load file or assembly '4f36378b-fe31-46d6-904d-48eb5b0bb8ca.tmp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. system cannot find the file specified.
When I check C:\temp\CSSCRIPT, there is correctly created folder \Cache-1372452907\ and three files:
css_info.txt
4f36378b-fe31-46d6-904d-48eb5b0bb8ca.tmp.compiled
4f36378b-fe31-46d6-904d-48eb5b0bb8ca.attr.g.cs

Any ideas?

Btw. this is my settings:
CSScript.AssemblyResolvingEnabled = true;
CSScript.GlobalSettings.TargetFramework = "v4.0";
CSScript.GlobalSettings.InMemoryAssembly = true;
CSScript.CacheEnabled = true;

[oleg-shilo]

C:\Temp\CSSCRIPT doesnt exist. Shouldnt it create it automatically?

It does. This is the implementation.

cs-script/Source/.NET Core/CSScriptLib/src/CSScriptLib/CSScript.cs

Line 88 in eaf0283

static public string GetScriptTempDir()

Though, it looks like you are using custom temp directory. If it is the case then it is your responsibility to create the temp dir.

...so I would "cache" the whole assembly... Is that ok?

Normally yes but not in this case. You are loading the assembly in the sandboxed domain and then trying to pass it back to your primary domain. This creates the problem and also defeats the purpose of your sandboxing. You can modify your code like below:

public Assembly Load(byte[] assemmbly)
{
    var asm = Assembly.Load(assemmbly);
    return asm;
}

And now you can verify with the debugger that you succeed loading the assembly and the error is raised when you try to return it.

Just in case.... want to emphasize again. All this have nothing to do with scripting. You are dealing with normal orthodox .NET challenges.

[pavelkux]

Hi Oleg,
again, thank you very much for your reply. The exception was really thrown when the successfully created assembly was returned to
return Sandboxer.Singleton.Load(System.IO.File.ReadAllBytes(asmInString));
here.

I am finally starting to understand the whole principle (and I am sorry I was not fully understanding it from the beginning). The problem I see is that the sandboxing in general might not work for me.

What is the current implementation:

• I have a business logic dll, which has an abstract class.
• This abstract class can be overriden and defined in the script.
• The business logic dll calls the invoke method on the script assembly and runs number of methods (either defined virtual or abstract in the abstract class).
• the business logic dll must have an access to IO.

Is it actually possible to achieve that? It seems like what you are saying is that I have to keep the objects created in the restricted assembly separated from the fully trusted dll. In that case this won't work for me, correct?

[oleg-shilo]

It is actually possible. It's not trivial but possible.

• You will need to keep your overridden class object in that external AppDomain. It's a given. This domain is your sandbox.
• You will need to carefully add the required permissions (e.g. IO) to your external domain.
• When defining your sandboxer class add all methods that your abstract class has and when they are invoked just map them to the overridden class instance methods.
• Do not cache the assembly but only the asssembly file.
• Because your sandboxer is derived from MarshalByRef you will be able to call its method from different domains.

interface  IWorker
{
   string Do(string arg);
}

internal class Sandboxer : MarshalByRefObject, IWorker
{
    IWorker worker; 
    public void Load(byte[] assembly)
    {
        worker = Assembly.Load(assembly).CreateObject("WorkerClass");
    }
   
    public string Do(string arg) => worker.Do(arg); 
   ...

Sandboxer.Sinleton.Init(externalAsselmblyFile);
IWorker worker = Sandboxer.Sinleton;
 
var result = worker.Do("test");

[pavelkux]

Oleg, once again, thank you very much for your effort!

I understand the suggested technique but this probably won't solve the problem. As far as I understand, the parameters and the return value of the "Do" function have to be non-domain objects. If I need to return something like an object of class defined in the business logic DLL and further use it in the business logic library it will also not work?

To be honest, I am thinking about kind of "hardcoded blacklist" which won't let the CSScript load the .cs file, if it contains any of the following strings:

• .Security
• .Registry
• .IO
• .Net
• .Storage
• .Reflection
• Activator.
• AppDomain.
• .Environment
• .Runtime
• .Windows
• .Threading
• .Diagnostics
• .Printing
• extern
• DllImport
• CSScriptLibrary.
• CSScript.

I absolutely understand that this is kind of amateurish solution but it should cover all the cases. What do you think?
Do you see any potential issues with this? Or any namespace of object which can still harm the client PC?

[LoneDebugger]

Hi,

I've been using CsScript for some time now and it is an amazing tool.

I was wondering if there is a way to run C# code with CsScript in a sandbox on .Net Core?

I have managed to run it in sandbox on .Net Framework, but i need to run it in sandbox on .Net Core now. As far as i have read in the internet, .Net Core does not support Code Access Security, so it seems that running the code in another AppDomain with limited permissions is not possible.

The purpose for this would be that we have a process management web service and web application, and users can edit their BPMN process diagrams with the web application and also add some script for the BPMN script tasks that the service will run with CsScript. But we really need to run the code in sandbox with limited rights or find another way to limit what the code can do for security reasons.

Do you have any advice?

[oleg-shilo]

@pavelkux, sorry I somehow missed your last post.

The sad reality is that .NET sandboxing has a few serious constraints:

1. it's not available on .NET Core.
2. It's performed in a separate AppDomain

First one does not have any work around. We are all at mercy of .NET Core team. :)

Th second point is a problem if you have to pass third-party types, which are not serializable and not inherited from MarshalByRefObject. It is a true problem and there are only two possible works around for that.

One is to use extra serialization to the types that can cross AppDomains:

// host
var result = script.Process(businessObject.ToJson(), processingContext.ToJson())
                   .FromJson<BObject>();

// script
string Process(string businessObject, string processingContext)
{
    var b_obj = businessObject.FromJson<BObject>();
    var context = processingContext.FromJson<Context>();
    . . .
    b_obj.ToJson());
}

Another approach is instead of having some script methods being executed in the temp AppDomain you can have the whole chunk of the business logic job done in this domain. This way you don't have to pass any rich types between domains.

---

Anyway, as a very last resort you can consider implementing your own "poor man sandbox".

An extremely aggressive approach would be to prevent the critical assemblies from being loaded:

AppDomain.CurrentDomain.AssemblyLoad += CurrentDomain_AssemblyLoad;
. . .
void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
    if (args.LoadedAssembly.FullName.StartsWith("System.IO,"))
        throw new SecurityException();
}

Softer but less reliable approach is to parse the script code and reject it if critical syntax tokens found. Very difficult to implement reliably.

Another one is to parse the script assembly instead, It may seem to be a daunting task but it is actually much simpler than it may seem.

Once I needed to find out if the assembly ever accesses the member of the specific DTO type property.
I was surprised how simple the end solution was. A simple reflection exercise. Thus you can try to check if the script assembly is invoking the "forbidden" API.

Though keep in mind none of this solutions will not give you 100% confidence. This is because the standard sandboxing raises the exception when the forbidden API is accessed. This can be determined with 100% accuracy.

You will need to determine the future intention of the script assembly. That can never be 100% accurate.

[pavelkux]

Hello Oleg,
thank you for your reply and I am sorry for the delay as well. I eventually decided to go with script parsing because the environment and the actual usage is not critical and also not really "public".
Thank you very much for your help and great support!
Keep it up please.
Pavel