Does CS-Script provide sandboxing out of box?

Question

I'm researching cs-script and I'm wondering about how secure it is, out of the box. I know a script is loaded and unloaded dynamically, but can that script escape its executing assembly? i.e. can it use reflection to access and instantiate classes from other assemblies in the same process?

So my question is does cs-script come with built-in security by default or does it not bother?

Answer 1

In short: No, CS-script does not provide any security features out of box.

Answered here: https://stackoverflow.com/a/8692459/1657476

The immediate attractive solution is to use .NET Sandbox. It is designed exactly for this sort of scenarios.The CLR standard sandboxing is available for the host application running scripts with CS-Script. The idea is that you initialise CAS before loading the suspicious script and the rest is a CLR responsibility. And if you need to configure directories/files permissions you do it with CAS tools. This way scripting is a "transportation" for the routine provided by your user. And CS-Script is a convenient mechanism for implementing such transport but the actual security concerns are addressed by .NET Sendoxing, which has comprehensive set of functionality to cover practically all possible security scenarios. With CS-script downloadables you can find the Sendboxing sample (\Samples\Sandboxing) which demonstrates how to prevent script from file I/O operations (e.g. create file).

A sample of using .Net Security Credentials with cs-script is available at: http://www.csscript.net/Samples.html (sandbox.zip)

To make execute an untrusted cs-script securely (as isolated as possible), create a new AppDomain with Security restrictions, before loading a script (into the new app domain). Data can then be marshaled between the primary- and script-domains. See https://msdn.microsoft.com/en-us/library/bb763046%28v=vs.110%29.aspx

Answer 2

If you mean CS-Script as per http://www.csscript.net/, then yes it can reference and call into other assemblies, with the normal syntax:

using MyOtherAssembly;

CS-Script uses implicit loading to try and work out which assembly to load based on the namespace in the using statement. This is not guaranteed to work in all circumstances, in which case you will need to use explicit loading, e.g., you can give CS-Script a directive to explicitly load the required assembly:

//css_ref "..\MyOtherAssembly.dll"
using MyOtherAssembly;

The //css_ref is a special comment that is processed by CS-Script as a directive to load the assembly, in this case the referenced assembly is in the parent directory of the script. This does a similar job as an assembly reference in a project file for a normal assembly. You can also use the CS-Script command line to explicitly load assemblies.

I have also found that you do not need to use either implicit or explicit loading if the referenced assembly has already been loaded into the AppDomain before the script is called. I assume CS-Script detects that the namespace already exists in the AppDomain, so does not bother with the implicit loading.

More information about the assembly loading is given here: http://www.csscript.net/help/using_.net_assemblies.html.

Edit1: You can't disable the implicit loading, but you could put the script into a directory without any other assemblies, which will prevent the implicit loading from being able to find any other assemblies. The script will still be able to call into namespaces that are already loaded. But this is only "security by obscurity"; the very nature of managed code means that it is always possible for a determined person to access your code via reflection.