Question and proposal: Can D be used to compile and run untrusted plug-ins?
ajieskola at gmail.com
Sat Dec 4 12:18:23 UTC 2021
On Saturday, 4 December 2021 at 11:33:21 UTC, Moamen Abdelsattar
> 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,
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).
More information about the Digitalmars-d