Question and proposal: Can D be used to compile and run untrusted plug-ins?

[Dukc]

On Saturday, 4 December 2021 at 11:33:21 UTC, Moamen Abdelsattar 
wrote:
> I've recently known that D functions can be marked as `@safe`, 
> which makes all unsafe operations unallowed inside the 
> function, my question is: Can this feature be used to compile 
> and run untrusted D code safely?
> I mean: Let's say We have a program written in D or C, and we 
> want to allow the user to extend the program by writing 
> plug-ins and compiling them into dynamic libraries (like 
> notepadd++ plug-ins).
> Now the plug-in can access all system calls and can do 
> something malicious, but what if the plug-in is written in D 
> and we have something like `-forceSafe` compiler flag (which is 
> the proposal) that will force every function written by the 
> user to be `@safe`. Now, the user can only import the 
> application's API and use it to perform functions and can't 
> access the system directly. Is that true?

No, `@safe` isn't suitable for that. For two reasons:

1: It only guards against memory integrity violations, not 
against otherwise malicious system calls. You can `@safe`ly 
delete everything in the home or "my documents" directory, or 
trigger a fork bomb. To prevent this, you have to not link any 
system calls to the untrusted module - which is perfectly doable, 
though.

2: The more difficult problem. It is not bug-free enough. `@safe` 
aims to be foolproof enough to prevent corrupting memory 
accidently, and it has enough challenge in that. It is more 
difficult to be so reliable that the memory could not be 
corrupted even by determined attempts. Perhaps in the far future 
it can do that, but not now nor anytime soon.


The same can be accomplished by sandboxing the compiled binary 
somehow though. For example, D program compiled to WebAssembly 
cannot corrupt the web browser running it, just like no 
WebAssembly program can (modulo browser vulnerabilities).