Development with a Dot

These are the posts in the series: Introducing Isolator - a framework for running isolated code for .NET Distributed Isolator Isolator with References Scanning Docker Support for Isolator

Introduction Some of you may remember - and hopefully have even tried! - my Isolator project . Isolator is a framework for running isolated code for .NET. What this means is that possibly unsafe code can be run in a secure, isolated, way. It offers some quite different isolation strategies: Process isolation : the code to execute runs in another process, possibly under a different identity (on Windows only) Assembly isolation : uses an assembly load context to isolate the code execution, which is then unloaded Distributed isolation : the code to execute is sent to possibly another server for execution Scanned : the code to execute is first checked for problematic code using my ReferencesScanner project Now, I added support for Docker isolation! What this means is, if you have Docker running on your machine, you can spawn an image that will just be used for running your code, and after that will be gone. This provides another very restricted level of isolation. For Docker A...

Introduction I recently posted about my projects  Isolator and ReferencesScanner , which allow us, respectively, to run .NET code in isolation and to list all of an assembly's references. Now, I'm going to present a change to  Isolator  that allows checking for a plugin's references with white and black lists. Any references on the white list will be allowed, and any on the black list will be denied. Using Isolator with References Scanning There is a new class, ScannedIsolationHost , which features four new properties: public HashSet<Type> SafeTypes { get; } public HashSet<Assembly> SafeAssemblies { get; } public HashSet<Type> UnsafeTypes { get; } public HashSet<Assembly> UnsafeAssemblies { get; } So, we have new properties: SafeTypes : list of Type references that are safe to use SafeAssemblies : list of Assembly references that are safe to use UnsafeTypes : list of  Type  references that are unsafe to use UnsafeAssemblies :...

Update: see my  other post  on references scanning , and  this one  on Docker. Introduction The purpose of Isolator , my framework for running isolated (sandboxed) code is to be able to, well, run code (known as plugins) on distributed, isolated instances (hosts). I initially created two isolation hosts: Process ( ProcessIsolationHost ): a new process is created to host and run the plugin Assembly Load Context ( AssemblyLoadContextIsolationHost ): a new assembly and assembly load context are created to host and run the plugin Now I'm introducing a new one, that allows to execute code on another machine:  ClientIsolationHost . I'll show you how to use it now. Client Host Isolation The idea is to be able to run code on a different machine, while keeping the same capabilities: We pass an existing plugin instance to the host which is then handled transparently Modified context properties are returned from the host to the caller Standard out...

Update: see my other post on distributed Isolator, this one on references scanning , and this one  on Docker. Introduction Code isolation, also known as sandboxes, are an important topic in any enterprise-level programming language: the means the ability to run code in a secure way that does not affect the main program. This used to be relatively easy to achieve with the .NET Framework, but it is no longer so, since .NET Core was introduced. I will talk a bit about it and how we can implement something similar. Code Isolation in .NET Custom app domains are gone from .NET since .NET Core. Officially they were removed because they were heavy and hard to maintain. There is still the AppDomain  class and we always have a current app domain, which can be accessed from AppDomain.CurrentDomain , but the AppDomain.CreateDomain method now returns an exception on all platforms. App domains were great, from a programatic point of view, because they allowed us to create new ones ...