Is it possible to safely sandbox C# code by analyzing the produced assembly?

[Tacodiva]

I would like to be able to compile and execute C# scripts at runtime in a sandbox. I would like to use a system like this:

1. Compile the scripts with allowUnsafe set to false.
2. Analyze the script's assembly to enforce a white-list of safe types, methods, and fields. If the CIL references anything not in the whitelist, refuse to continue.
   • The whitelist would have to prevent the usage of some language features, like dynamic (as it would block the reflection methods required for dynamic to work).
3. Analyze the script's assembly to look for unsafe CIL emitted by the pseudo attributes.
   • Make sure all structs have a sequential memory layout.
   • Make sure no methods are internalcall or pinvokeimpl.
4. Load the assembly into the runtime and execute the scripts.

Assuming the white-list is secure and enforced correctly, is this a safe way to sandbox scripts? Note that I am not worried about denial of service attacks with infinite loops or crashing, I only care that that code is not able to "infect" the broader system.

I guess the real question is if there is a way to produce unsafe access or reflection without having the assembly reference any types/methods/fields which are not white-listed. As a hypothetical, the Unsafe.Unbox methods seems to always compile to the call CIL instruction, thus can be caught by the checker, but if it was able to compile directly into an unbox instruction, the whitelist would not be able to identify it as unsafe code.

[huoyaoyuan]

It's theoretically possible, but may not be practical. The current .NET libraries are designed for in-process isolation. There may be undiscovered holes that allows accessing wide global state. Limiting access to a narrow range like API of host system and common collections only may work.

Besides dynamic and reflection, all the memory unsafe API should also be covered, including Marshal, MemoryMarshal and Unsafe. The memory safety proposal covers them.

• Make sure all structs have a sequential memory layout.

Note that auto layout is also safe.

As a hypothetical, the Unsafe.Unbox methods seems to always compile to the call CIL instruction, thus can be caught by the checker, but if it was able to compile directly into an unbox instruction, the whitelist would not be able to identify it as unsafe code.

It's covered by the verifiability of IL. However, some modern C# features aren't supported by verification yet.

[Tacodiva]

Thank you for your response :)

Limiting access to a narrow range like API of host system and common collections only may work.

I am considering this for a game engine which is loading scripts as addons for the game. If I were going to rely on this, I would limit access greatly and write my own APIs which I can make sure are safe to expose most things.

It's covered by the verifiability of IL. However, some modern C# features aren't supported by verification yet.

Could you tell me more about that? What exactly do you mean that some new features are not supported by verification yet?

I've also been trying to figure out if those weird hidden keywords (__arglist, __makeref, __reftype, __refvalue) could cause problems for this approach. I can disallow __arglist methods, but still not sure about the others. I would probably analyze the syntax with Roslyn first as well to look for these and double check the whitelist as well just to be on the safe side.

[huoyaoyuan]

It's mostly about the unstability standalone ILVerify tool. Built-in verification in clr has been disabled for .NET Core.

I've also been trying to figure out if those weird hidden keywords (__arglist, __makeref, __reftype, __refvalue) could cause problems for this approach.

They should actually be safe. All the unsafety are sealed inside the TypedReference type.

[Clockwork-Muse]

Note that this is one of the major reasons to create (or find) a Domain-specific language/embedded engine. The (user-provided) game scripts must be written in this language, which implements only a safe set of features. There is no validator here - only safe APIs (or wrapped ones for things like file IO) are even available for compilation. For example, miniscript (haven't used this, but from 10 seconds of searching).

Going this route will likely be easier and safer overall, and also allows you to potentially change the underlying engine implementation without disrupting user code.

[Tacodiva]

Note that this is one of the major reasons to create (or find) a Domain-specific language/embedded engine.

You're right, it would definitely be safer to use something else. However, I am chronically addicted to C#.

I would be making a safe API for the scripts myself anyways, minimal types from the standard library would be allowed. My game engine is written in C#, so the benefits of using C# as a scripting language directly would be ease of interoperability and performance. Probably still a bad idea, but I still want to experiment with it.