No debes imaginar las cosas como una "lista negra" de cosas para atrapar. Las listas negras no funcionan . Al menos, no funcionan bien. En lugar de intentar elaborar una lista de "llamadas prohibidas al sistema", debe crear una lista de "llamadas al sistema definitivamente inocuas" que permita explícitamente.
Lo que necesitas es un sandbox . El navegador web de Chromium (la parte de código abierto de Chrome) contiene tal caja de arena que funciona en Windows. Esa página contiene una arquitectura bastante detallada del sistema sandbox. No sé hasta qué punto este mecanismo de espacio aislado se puede extraer del código fuente de Chromium y se puede usar solo.
Si desea algo más utilizable de forma inmediata, puede investigar máquinas virtuales . En ese modelo, le da un sistema operativo y una máquina completos al código del cliente, y controla las cosas "desde afuera": la máquina virtual se comunica con el mundo externo a través de una interfaz de red, y el sistema host (su servidor) controla exactamente qué paquetes Hazlo a través y cuáles no. Por ejemplo, si desea que el código del cliente acceda a algunos archivos locales desde su servidor, simplemente exporte (como un "recurso compartido de red") el directorio específico a la VM. Para una máquina virtual invitada con pocos recursos, sugiero NetBSD , que es notoria por requerir muy poca RAM.
Editar: independientemente de la tecnología que use (sandbox, VM ...), ejecutar código potencialmente hostil en sus sistemas puede ser peligroso. De hecho, todos los fragmentos de código que se ejecutan simultáneamente en una máquina determinada necesariamente comparten algunos recursos, es decir, cachés L1, cachés de predicción de saltos ... que pueden usarse para obtener información sobre otros fragmentos de código, ya sean otros usuarios de su sistema o código del propio anfitrión. Esto se ha demostrado como parte de los ataques para recuperar nada menos que una clave de cifrado AES, es decir, el Secreto de los Secretos en un sistema criptográfico. Consulte, por ejemplo, esta respuesta . Aunque la demostración se realizó en sistemas de encriptación, esto realmente afecta a cualquier cosa que usted hace en una computadora con datos confidenciales.
Por lo tanto, si tiene datos confidenciales en su servidor, o si algunos de sus usuarios pueden encontrar una ventaja para espiar a otros usuarios, entonces ... no lo haga.
Para mitigar este espionaje cruzado, tendría que hacer que el código del recinto no pueda comunicarse con el mundo externo (excepto para devolver un "resultado" al final) y para desactivar las instalaciones para una medición precisa del tiempo transcurrido (a saber, el código de operación rdtsc en x86 - se puede desactivar con una bandera en el registro CR4, pero no sé si las soluciones de virtualización habituales ofrecen una forma sencilla de hacer cumplir esta desactivación).