title: Plugin system security in .NET Framework 4.x (without CAS)
body: <p>What I'd like to achieve is a plugin system with the following features:</p>
  
  <ul>
  <li>loading external plugins, from sources potentially not trusted by me (the developer), but trusted by the end-user who installed the plugin</li>
  <li>granting per-plugin permissions within a specific scope; e.g. one plugin may have a permission to read files from a specific location, while others may be allowed to connect to specific website location</li>
  <li>a special case of per-plugin permissions: interacts with another object, most likely provided as an interface instance, without accessing any of its non-public members (not even with sneaky Reflection techniques)</li>
  <li>prevention of actions the end-user didn't agree to, such as accessing non-public members or operating on the filesystem, before the plugin code can do any harm</li>
  </ul>
  
  <p>During my search, I've mostly found SO solutions involving Code Access Security which, as far as I know, is outdated as of .NET 4.x. I've also read up a bit on the new security model on MSDN pages, and it seems <a href="https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines#library-code-that-exposes-protected-resources" rel="noreferrer">library code that exposes protected resources</a> will be necessary here; however, I could not find any examples showing how to apply such code. My guess is that it'll involve creating separate AppDomains and possibly playing around with Principal permissions, but that's about as far as my knowledge gets.</p>
  
  <p>On a side note, I've also found mentions of requiring strongly named assemblies only, but I'm not convinced that'll be enough. If I'm not mistaken, one of the strong naming benefits is that the plugin developer can prove their own identity by signing the assembly hash with own private key, and others can check by using well-known and trusted public key. However, this alone seems too inflexible, as it either requires the developer to personally decide whose code should be trusted or just trust anyone who learned to sign their assembly.</p>
  
  <p>I'll be very grateful for a good example of security management code using the most up-to-date security model. What I currently have in mind:</p>
  
  <ul>
  <li>an interface for service exposing potentially sensitive operations (say, A and B)</li>
  <li>a dummy implementation of the service, focusing on preventing the unauthorised execution of these operations</li>
  <li>two plugins from separate assemblies, one with permission to perform operation A and other with permission for operation B</li>
  <li>an application that sets up the service, loads the assemblies with plugins and tries to perform operations for each of these, so that unauthorised operations are blocked and authorised operations are executed correctly</li>
  <li>when run within the application, neither plugin on its own should be able to access general sensitive APIs, such as file I/O or networking, but it should be possible to do through the service</li>
  <li>all that while following <a href="https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines" rel="noreferrer">these recommendations</a> as closely as feasible (as opposed to CAS-based solutions from SO questions back from year 2010)</li>
  </ul>
  
  <p>Of course, you are welcome to suggest an alternative architecture, if it achieves the goal in a better way.</p>