En primer lugar, ten en cuenta que lo que estás intentando es extremadamente difícil de acertar. Por ejemplo, una gran cantidad de herramientas en Windows están en el directorio System32 (y SysWOW64, donde corresponda), por lo que puede estar tentado a negar el permiso de Ejecución en ese directorio (excepto en algunos EXE críticos), pero eso evitará que se carguen DLL. que se requieren para casi todos los programas de Windows. Algunas cosas compartidas / muy necesarias también están en los Archivos de programa, por lo que el mismo riesgo se aplica allí.
También ten en cuenta que Windows no hace que sea fácil hacer cosas como esta. De forma predeterminada, cualquier usuario puede omitir las restricciones de recorrido del directorio (como en * nix, el bit de Ejecución en un directorio ACL controla la capacidad de acceder al contenido del directorio, pero a diferencia de * nix, esta restricción se ignora de forma predeterminada). Además, aunque las ACL de Windows se heredan de forma predeterminada, algunos elementos no no usan permisos heredados. Por ejemplo, el directorio C: \ ProgramData no hereda los permisos de C: \ y, de forma predeterminada, permite que cualquier miembro de los Usuarios (que de manera predeterminada incluya Usuarios Autenticados) cree subdirectorios y tenga control total sobre esos subdirectorios. Esto hace que sea muy difícil crear una cuenta de usuario que pueda solo escribir en una ubicación.
Dicho esto, sí, esto es posible. Las ACL de Windows se validan contra un token de proceso en el siguiente orden: denegación de usuario, permiso de usuario, denegación de grupo, permiso de grupo. Por lo tanto, si un usuario es miembro de un grupo permitido (como Usuarios autenticados, es decir, cualquier persona que haya iniciado sesión con credenciales) y un grupo bloqueado (como los Invitados integrados o un grupo personalizado que cree y agregue a Invitados), entonces el usuario será bloqueado. Sin embargo, si también otorga explícitamente al usuario acceso en esa ACL, eso anula las protecciones de grupo. Esto significa que puede bloquear a un grupo para que no haga algo globalmente y luego otorgar a sus miembros acceso a recursos específicos.
Un enfoque alternativo para las ACL sería usar AppLocker ("Políticas de control de aplicaciones"), que le permite hacer cosas como deshabilitar todos los programas, excepto una lista blanca especificada por la firma del editor, el hash de archivo, etc. Una explicación completa del uso de AppLocker está fuera del alcance de esta respuesta, pero puede encontrar información en línea o comenzar a jugar con ella usando el editor de Políticas de seguridad locales ( secpol.msc ). Tenga en cuenta que si se ensucia lo suficiente puede inutilizar la máquina. Tenga en cuenta que AppLocker generalmente es solo se puede usar en Enterprise o -mejoras ediciones .
No hay una forma equivalente (a AppLocker) de restringir el acceso a los archivos, pero puede hacer esto usando Control de integridad obligatorio . Si restringe a un usuario para que solo ejecute un determinado conjunto de aplicaciones (o solo ejecute aplicaciones desde un directorio determinado), puede especificar que los EXE (o directorio) tengan un nivel de integridad bajo. Por lo tanto, cualquier proceso iniciado desde esos EXE también será de baja integridad, lo que evitará que se escriba en cualquier archivo o directorio con una integridad superior a la de Low (de forma predeterminada, todo es integridad de Medium). Tendrá que tener cuidado de que esto no cause problemas, por ejemplo, los programas que generan archivos de registro deberán poder escribir en su directorio de registro, pero se puede hacer.