Securing a plugin system:
Is there any alternatives to app domains in dotnet 9 for preventing access to the file system when implementing a plugin system using AssemblyLoadContext?
Tout of process + RPC such as JsonRPC or other
Tand uses whatever OS security feature exists on the Os running
JThe issue is I’m trying to use dependency injection to provide access to configuration and input details to the plugins
JIf I was to do a grpc style plugin system how would I register the plugins ?
Epersonally i might recommend wasm, but it's in very early stages at the moment, especially for .net
Ea wasm component (or module) would be sandboxed
Efrom there, you can use simple function imports and exports
Eand for even more complicated data transfer (wasm will only allow you to pass basic integers), you can allocate some shared memory, i believe, that both sides can read?
i'm not sure on that one, but check out
i'm not sure on that one, but check out
Extism if you wanna go that route. it's a library for wasm plugin creationEwasm gives you the extra advantage of being able to write the plugins in any language that can compile to wasm (which is basically every language)
JThat would be interesting but can it use interfaces from C sharp? The idea is to have a cli tool that people can add custom plugins to, to suit their purposes
Eyou would provide a compatibility layer, of course
Eyour own plugin sdk
JThat looks really interesting actually
JSo instead of passing interfaces I’d need to write a compatibility layer that lets the plugin request data from the host application?
Eit's possible to write a compatibility layer for this direction, yes
Eif you would like the plugin to send data to the host, it might be more complicated, if not impossible
Eyou cannot forward exports
Efrom one project to another
JIs it possible to get the list of functions a wasm plugin has ?
Evia c#?
Ei'm not sure
Ebut you can also simply throw if an export doesn't exist :p
Ethat's an exceptional case i wouldn't handle
Eextism might just have a way to query exports
Ebut yeah this part of it isn't so nice to work with, it's not super easy to provide users with an actual ready to go solution
Eunless you wanna go with project templates or source generation
Tforget about having DI working between your core app and your plugin
Tthat's why last time when everyone was having the bang wagoon of autofac i was explaining it was unrelated
Tand people still went for it
Tif you want isolation
Tyou're isolated from memory
Tyou're not sharing the same space
Tyou're outsite
Tthere's no magic resolution accross safe boundary
Tyou use a wire and communicate via wire
Tagain the idea of using autofac for "container isolation" doesn't have any relation what so every with security
Tit's just a glorified
.GetService<IServiceProvider>("tenantName") with a pass throughTwhere you'd create a unique
IServiceProvider per plugin + a lookupT=========
TLDR: if you're still in the same memory / process i'd just spin reflection and inject what I want in the core process
you can't do anything about it and you can't protect against and and you can't block disk access
TLDR: if you're still in the same memory / process i'd just spin reflection and inject what I want in the core process
you can't do anything about it and you can't protect against and and you can't block disk access
T=========
Tso you move to sandboxing process: that being [ container / wasm / outofprocess + OS restriction ] + RPC
SUsing:
Here's a MVE for WASM sandboxing in dotnet. Maybe this is useful to you. Steve Sanders has a video on his YT channel on the package.
https://github.com/SleepWellPupper/ConsoleApp1/blob/4d638be8f6f895532718b82bcb04647ea468d5d0/ConsoleApp1/Program.cs#L233-L304
<PackageReference Include="DotNetIsolator" Version="0.1.0-preview.10032" />Here's a MVE for WASM sandboxing in dotnet. Maybe this is useful to you. Steve Sanders has a video on his YT channel on the package.
https://github.com/SleepWellPupper/ConsoleApp1/blob/4d638be8f6f895532718b82bcb04647ea468d5d0/ConsoleApp1/Program.cs#L233-L304
