Valójában egy rakás izolácós réteg van, csak mind szar. 386 óta van az úgynevezett protected mode, ami a programok memóriaterületeit szétválasztja egymástól és az oprendszertől is. Tehát egy sima program eleve be van zárva egy sandboxba. (Vagy talán 286 óta is van? Azt nem ismerem, de mintha rémlene, hogy már abban is volt ilyen funkció, de az oprendszer ami tudta használni is, az nem terjedt el.)
Sajnos a sors iróniája, hogy az oprendszerek által adott API-k, amiken keresztül a programok kikukkantanak a saját homokozójukból tele vannak hibákkal, és emiatt ez a réteg nem bizonyult elégségesnek. A magánvéleményem az, hogy ezen a szinten szükséges volna egy modularizált rendszert építeni, ami a programok számára egy lekorlátozott API-t tudna adni. És annak a korlátozott API-nak lehetne egy részhalmaza, ami biztonságosnak tekinthető, és ami csak azt használja, azt lehetne futtatni bátran. Ilyesmit akart szerintem a Google Native Client csinálni: https://en.wikipedia.org/wiki/Google_Native_Client
A Docker, Flatpak, stb izolációk amennyire tudom nem is törekednek arra, hogy biztonságosak legyenek egy támadó ellen is, hanem csak arra, hogy a függőség kezelés független legyen alkalmazásonként, és valamennyire elválaszthatóak legyenek az erőforrások. Hasonló a wine is, amiből szintén tud egyszerre több működni, de az sem izolál biztonságosan.
A böngésző a JavaScriptet sandboxban futtatja, ezt eléggé biztonságosnak tartják manapság.
Vannak a virtuális gépes programnyelvek. Például a Java is ilyen. Ebből is elvileg lehet biztonságos sandboxot csinálni, de úgy tudom, hogy abban is folyton előjönnek biztonsági hibák, és nem nagyon szokás ilyesmire használni. Itt is a modularizálás segíthetne szerintem: kellene egy biztonságos minimum, amit még lehet könnyen auditálni. Ami meg annál több, ott felesleges a törekvés is.
Úgy tudom, hogy van olyan irány is, hogy a kernelben futtatható "virtuális gép" is készül. Ennek az a lényege, hogy a virtuális gép általi izoláció olcsó tud lenni, mert úgy tud biztonságosan kódot futtatni, hogy a hardver izolációt nem kell használni. Tehát a kernel kontextusban futhat user kód. Miért van szükség erre? A nagy teljesítményű IO esetén az alkalmazás-kernel határ átlépése bizonyul a legnagyobb költségnek. Ezt meg lehet spórolni, ha az alkalmazás egy része a kernel kontextusban fut. De a Kernel is biztonsági értelemben izolált a user processzektől Linux esetén ugye. Ezért csak egy bizonságosan korlátozott virtuális gépet lehet a Linux kontextusban futtatni az alkalmazás által.
Szerintem egyébként a teljesítmény miatt arra is volna igény, hogy ne legyen izoláció a kernel és az alkalmazások között se, vagy pedig könnyen tudjuk kernel kontextusban user kódot futtatni. Például beágyazott rendszerek, vagy pedig egyetlen szolgáltatásra dedikált szerverek esetén az izolációnak semmilyen haszna nincsen (azon kívül, hogy az alkalmazás crash-je esetén magát az oprendszert nem kell újraindítani), és ezekben az esetekben meg lehetne ezeket spórolni. Bizonyos terhelési profilok esetén meglepően sokat számít a user-kernel határ átlépegetésének a költsége.