Prima di tutto, tieni presente che ciò che stai tentando è estremamente difficile da ottenere. Ad esempio, molti strumenti di Windows si trovano nella directory System32 (e SysWOW64, dove applicabile), quindi potresti essere tentato di negare l'autorizzazione Esegui su quella directory (tranne forse su alcuni EXE critici), ma ciò impedirà il caricamento delle DLL che sono necessari per quasi ogni singolo programma Windows. Alcune cose condivise / ampiamente necessarie sono anche in Program Files, quindi lo stesso rischio si applica lì.
Nota anche che Windows non rende facile fare cose come questa. Per impostazione predefinita, qualsiasi utente può ignorare le restrizioni di attraversamento della directory (come su * nix, il bit Execute su una directory ACL controlla la possibilità di accedere ai contenuti della directory, ma diversamente da * nix, questa restrizione viene ignorata per impostazione predefinita). Inoltre, mentre gli ACL di Windows sono ereditati per impostazione predefinita, alcuni elementi non utilizzano autorizzazioni ereditate. Ad esempio, la directory C: \ ProgramData non eredita le autorizzazioni da C: \ e per impostazione predefinita consente a qualsiasi membro di utenti (che per impostazione predefinita include Authenticated Users) di creare sottodirectory e di avere il pieno controllo su tali sottodirectory. Ciò rende molto difficile creare un account utente che possa solo scrivere in una posizione.
Detto questo, sì, questo è possibile. Gli ACL di Windows vengono convalidati su un token di processo nel seguente ordine: Nega utente, Consenti utente, Nega di gruppo, Consenti gruppo. Pertanto, se un utente è membro di entrambi i gruppi consentiti (come Authenticated Users, ovvero chiunque abbia effettuato l'accesso utilizzando le credenziali) e un gruppo bloccato (ad esempio gli ospiti incorporati o un gruppo personalizzato creato e magari aggiunto a Ospiti), quindi l'utente verrà bloccato. Tuttavia, se anche concede esplicitamente all'utente l'accesso in quell'ACL, che sovrascrive le protezioni di gruppo. Ciò significa che puoi bloccare un gruppo dal fare qualcosa a livello globale, quindi concedere ai suoi membri l'accesso a risorse specifiche.
Un approccio alternativo agli ACL consiste nell'utilizzare AppLocker ("Criteri di controllo applicazioni"), che consente di fare cose come disabilitare tutti i programmi tranne una lista bianca specificata dalla firma del publisher, dall'hash del file o così via. Una spiegazione completa sull'utilizzo di AppLocker non rientra nell'ambito di questa risposta, ma puoi trovare informazioni online o iniziare a giocare da solo utilizzando l'editor di Criteri di sicurezza di Locals ( secpol.msc ). Si noti che incasinare abbastanza male può rendere la macchina inutilizzabile. Tieni presente che AppLocker è generalmente utilizzabile solo su Enterprise o -etizioni migliori .
Non esiste un modo equivalente (a AppLocker) per limitare l'accesso ai file, ma puoi farlo usando Windows Controllo di integrità obbligatorio . Se si limita un utente a eseguire solo un determinato insieme di applicazioni (o solo a eseguire applicazioni da una determinata directory), è possibile specificare che gli EXE (o la directory) hanno un livello di integrità basso. Qualsiasi processo avviato da tali EXE sarà quindi anche solo a bassa integrità, che impedirà di scrivere su qualsiasi file o directory con un'integrità più alta di Bassa (per impostazione predefinita, tutto è Media integrità). Dovrai fare attenzione che ciò non causi problemi: ad esempio, i programmi che generano file di log dovranno essere in grado di scrivere nella loro directory di log, ma è possibile farlo.