Securing DATEX Endpoints against Code Execution Attacks

[asbng]

This is a very important topic if we intend to offer more than a prototyping technology. As the DATEX Language becomes larger, so does its potential to cause harm when an endpoint executes code by an untrusted sender. We should define what exact parts of the language may be sent to be executed at a remote endpoint without allowing DoS attacks and other abusive actions.

[benStre]

I think we should split this discussion into two separate discussions points:

1. Prevention of DOS attacks - this includes a lot more than just the DX code execution, e.g. Rate limiting on the routing level, blacklisting endpoints, and of course also preventing excessive calculations (like recursive calls etc.) when executing remote DX code. Protocols like GraphQL face similar issues with complex queries, maybe we can also take some inspiration from there.
2. Actual Code Execution Attacks a.k.a. remote code execution a.k.a. sandbox escapes - this is a complete separate topic imo, we are talking about remote endpoints somehow exploiting their capability of "executing" DATEX code and escaping the predefined sandbox. Since we are using Rust, it should never be possible to use "low-level" vulnerabilities like buffer overflows, use after free etc., but we still need to make sure that the DATEX runtime itself does not have vulnerabilities which enable sandbox escapes. And if we ever introduce file system utilities or similar functions to the DATEX std library, they should never be accessible by remote endpoints per default.