In general, sandboxes don’t work well at the language level. You really need to go at the system level.
Even at the language VM level, it doesn't seem to be tenable.
Microsoft tried to go all out on this back in the day with Code Access Security. I remember three things about it:
1. Engineers/sysadmins would easily get frustrated, and just let the app run under full trust
2. Perf issues, since security demands would result in checking the call stack up
3. When they changed things in .NET 4 a lot of web code would break unless you added a magical attribute.
Needless to say, microsoft more or less gave up on it in .NET core
Unfortunately supply chain security is incompatible with developer convenience. At least not without a lot of work to make it bearable.
We will have to suffer through a lot worse attacks than now before people will take it serious (most developers likely never but governments will at some point intervene - see EU's CSA).
Back then, you often just ran VS as local admin, supply chain attacks weren't a 'real' thing most of the time, so NBD.
So then you try to deploy your app, and discover the joys of signed assemblies.
And you -make absolutely sure- when you leave, you give instructions to rebuild the whole pipeline if need be.
TBH at least we knew there was the polite illusion of a sandbox...
There you can more exactly specify what a function may do, instead of relying on blunt categories like "filesystem".
However, there is some appeal to the syntax introduced by the author if we use it for a proper and portable sandboxing mechanism. Maybe WASI, with capabilities?
To be more specific, there’s no reason for rust to know that writing to a specific file will allow modifying the program’s memory. It’s also not a security problem from the system, it’s just how it works. It really only makes sense for the system to enforce that kind of sandboxing, because it has enough context to enforce things sensibly.