Non dovresti immaginare le cose come una "lista nera" di cose da intrappolare. Le liste nere non funzionano . Almeno, non funzionano bene. Invece di cercare di elaborare un elenco di "chiamate di sistema vietate", dovresti invece creare un elenco di "chiamate di sistema assolutamente innocue" che autorizzi esplicitamente.
Ciò di cui hai bisogno è una sandbox . Il browser Web Chromium (il lato open source di Chrome) contiene un sandbox di questo tipo che funziona su Windows. Quella pagina contiene un'architettura piuttosto dettagliata del sistema sandbox. Non so fino a che punto questo meccanismo sandbox possa essere estratto dal codice sorgente Chromium e usato da solo.
Se vuoi qualcosa di più immediatamente utilizzabile, allora potresti voler esaminare macchine virtuali . In quel modello, fornisci un sistema operativo e una macchina completi al codice client e controlli le cose "dall'esterno": la VM parla al mondo esterno attraverso un'interfaccia di rete e il sistema host (il tuo server) controlla esattamente quali pacchetti farcela e quali no. Ad esempio, se si desidera che il codice client acceda a alcuni file locali dal proprio server, quindi si esporta (come "condivisione di rete") la directory specifica della VM. Per una VM guest con risorse limitate, suggerisco NetBSD , che è noto per richiedere pochissima RAM.
Modifica: indipendentemente dalla tecnologia che utilizzerai (sandbox, VM ...), l'esecuzione di codice potenzialmente ostile sui tuoi sistemi può essere pericolosa. Infatti, tutti i frammenti di codice che vengono eseguiti contemporaneamente su un determinato computer condividono necessariamente alcune risorse, ad esempio cache L1, cache di previsione di salto ... che possono essere utilizzate per ottenere informazioni su altri frammenti di codice, che si tratti di altri utenti del sistema o codice dall'host stesso. Ciò è stato dimostrato come parte degli attacchi per recuperare nientemeno che una chiave di crittografia AES, ovvero il segreto dei segreti in un sistema alimentato crittograficamente. Vedi ad esempio questa risposta . Anche se la dimostrazione è stata fatta su sistemi di crittografia, questo ha davvero un impatto qualsiasi cosa che si fa su un computer con dati riservati.
Pertanto, se disponi di dati riservati sul tuo server o se alcuni utenti potrebbero trovare vantaggioso spiare altri utenti, allora ... non farlo.
Per mitigare l'intercettazione di tali cross-sandbox, dovresti fare in modo che il codice sandbox non sia in grado di comunicare con il mondo esterno (tranne per restituire un "risultato" alla fine) e disattivare le strutture per la misurazione precisa del tempo trascorso (ovvero l'opcode rdtsc su x86 - può essere disabilitato con una bandiera nel registro CR4, ma non so se le solite soluzioni di virtualizzazione offrono un modo semplice per far rispettare questa disattivazione).