> any step is a potential minefield

That's the exact problem with C. It's the tool, not the attitude, which is a problem.

Securely containing untrusted user code so that it can't do any harm is ultimately the responsibility of the OS, or whatever sandbox the code is running in.

Language-level memory safety is useful for eliminating an important class of bugs, but if those bugs can be exploited to escape the sandbox, then that's the problem of the sandbox, not of the buggy program running in that sandbox. So please, by all means, write the sandbox itself in a memory safe language like Rust, but requiring the same for all code running inside the sandbox is nothing more than an admission of failure.

What if the sandbox, kernel, device drivers are written in C? Sounds like a good case against C for these uses.

Yes, I fully agree! But such subtleties are usually overlooked by the 'C users are criminals' crowd ;)

That's pretty limited way to look at it. You don't need to escape the sandbox to do harm.

You can have your app in perfect sandbox where nothing can escape then have a memory safety bug inside allowing user to get to the stuff of another user (because your sandboxed app talking with sandboxed database still have one set of credentials to do everything)

There is of course https://xkcd.com/1200/ for that.

And no "move that separation to DB" also isn't a solution.

I agree, same with popular multiplayer games for instance which could be exploited by memory safety bugs in the network protocol implementation. But these are cases where just implementing a couple of critical modules either with a memory-safe language, or using code generation (or both) to reduce the amount of 'manual bugs' go a long way. AFAIK exploits almost always happen in places where data comes into the system, so those are the places to focus on.

Imagine any other engineering field complaining about safety being a mental drain.