I need to allow some users to upload some plugin dll that would run on the server (based on asp.net core) as some custom script (I dont want to use javascript or any other languages to limit the api accessibility). How can I keep the user dlls from accessing the .net APIs such as System.IO to avoid the potential security problems on my server?
-
you can't restrict what code runs in .net. .net core doesn't have trust levels and that was found to be broken. – Daniel A. White Mar 27 '18 at 01:51
-
There must be some solution to restrict, but I dont know how to do that. see [the official online code tester](https://www.microsoft.com/net/learn/in-browser-tutorial/1) @Daniel A. White – Alsein Mar 27 '18 at 02:05
-
You could run it in a docker container. That would be more isolated – Daniel A. White Mar 27 '18 at 02:06
-
no it does not actually solve the problem for the external dll would also be able to influence the current service @Daniel A. White – Alsein Mar 27 '18 at 02:10
-
no - define a contract that dll has to implement. make it a console app or a web app. but ask the consumer to write it in a docker container. run against that service - you can either skip the container or not for your app – Daniel A. White Mar 27 '18 at 02:12
-
anytime you run any code on your server, it is a hard problem to effectively sandbox it. – Daniel A. White Mar 27 '18 at 02:12
-
what i want to do is to execute some logical codes from the plugin dll and keeping it from accessing anything else, not to let it destroy the service just keeping the server machine safe @Daniel A. White – Alsein Mar 27 '18 at 02:14
-
thats a hard problem. theres plenty of DSL languages or you could design your own to restrict the API surface. but theres nothing like that built in to .net core. – Daniel A. White Mar 27 '18 at 02:15
-
as long as microsoft releases that online compiler (and there are many similar online code testing service from other sites), there must be some systematic solutions @Daniel A. White – Alsein Mar 27 '18 at 02:18
-
in a multitenant service i cannot just create new docker containers for every single user. sandboxing it at system level is inadvisable @Daniel A. White – Alsein Mar 27 '18 at 02:25
-
https://twitter.com/thetrueaplus/status/978464342923448325?s=21 – Daniel A. White Mar 27 '18 at 09:32
-
yes indeed, but if accessing the file system or doing some similar things would result throwing exceptions, which means this code is sandboxd on code level. – Alsein Mar 27 '18 at 10:18
-
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/167624/discussion-between-alsein-and-daniel-a-white). – Alsein Mar 27 '18 at 10:24
1 Answers
.NET Core does not provide any code sandboxing, isolation, code security features like how previous versions of the .NET Framework did with AppDomains and trust settings. These features were found to be insecure and omitted from .NET Core from the get go.
However, if you still want to run code (.NET Core or not) from an external source there's several options.
Create your own DSL. This is what Salesforce has done with Apex. If the language gives your developers everything they need and limit what they can do, this is a solid option. JavaScript would be a great option as you can define what calls can be made into the .NET side if you use a .NET JavaScript interpreter and you wouldn't have to reinvent the wheel. Node.js would work but you would run into that it has a rich API for accessing "the outside world"
Use Docker. Docker containers are really isolated and can't directly touch the outside world without your permission. This is how the .NET example runs work. They can't do damage to the host machine unless you give them permission to do so.
Anytime you load code into your process you are opening the gates for them to do anything that your process can do.

- 187,200
- 47
- 362
- 445