Separating the runtime from the business logic doesn't really work because the business logic has the authority to do anything it has the authority to do. It's the https://xkcd.com/1200/ problem all over again.
I don't think so. Business logic just works with data it has access to. Backup, encryption, access control can be separate concerns. A good programming stack would make sure you don't have RCE.
Flawed business logic might corrupt data, but that's much less rare than security vulns, and might be solved by versioning data (e.g. copy-on-write, even Windows had Volume Shadow Copy service which can take a snapshot of all data).
The main problem is that there's no incentive for software vendors to separate parts: e.g. app which processes financial records might also send/receive data over internet. If user had a more explicit control over flow of data (e.g. imagine n8n style pipeline) many logic flaws like sending data to wrong place could be eliminated.
It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.
> Business logic just works with data it has access to. Backup, encryption, access control can be separate concerns. A good programming stack would make sure you don't have RCE.
The problem is that the business logic tells everything else what to do and has authority to do everything that the program can do. Exploiting that way is fiddlier (it's like doing ROP only more so), but ultimately once the software gets into an unintended/unexpected state it's game over.
> It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.
Many have tried. If you try to require fine-grained permissions and user in the loop people just say yes to everything. Ultimately the user thinks they want to do the thing they said to do, and asking them again won't change that.
Flawed business logic might corrupt data, but that's much less rare than security vulns, and might be solved by versioning data (e.g. copy-on-write, even Windows had Volume Shadow Copy service which can take a snapshot of all data).
The main problem is that there's no incentive for software vendors to separate parts: e.g. app which processes financial records might also send/receive data over internet. If user had a more explicit control over flow of data (e.g. imagine n8n style pipeline) many logic flaws like sending data to wrong place could be eliminated.
It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.