Esiste una combinazione di permessi di Windows che consente l'esecuzione di un eseguibile .NET ma non la lettura né la copia del suo contenuto?

0

Suppongo che se un file è eseguibile da chiunque, in altre parole, se un utente ha abbastanza autorizzazioni per eseguire un eseguibile in Windows, sarà possibile leggere il contenuto dell'eseguibile e copiarlo in un'altra directory in uno modo o altro. Tuttavia, ho cercato di dare solo il permesso di esecuzione e di non leggere il permesso per un eseguibile e sono stato in grado di farlo quando il file è un EXE ma non quando l'eseguibile è un file .NET .

In questo caso ho usato questa combinazione di permessi:

È possibile consentire solo l'esecuzione di un eseguibile .NET e disabilitare la copia del file in un'altra directory o aprirla con un disassemblatore o un debugger?

    
posta kinunt 03.07.2013 - 17:26
fonte

3 risposte

7

(Attenzione: qui sto facendo alcune "congetture istruite", in particolare per analogia con ciò che accade in altri sistemi operativi.)

Il comportamento che descrivi è normale: un eseguibile .NET è in realtà una specie di script. Dal punto di vista del kernel del sistema operativo, non esiste ".NET". Il kernel conosce i file eseguibili . Per il kernel, è possibile accedere a un file per lettura (un'applicazione apre il file e quindi legge i byte con chiamate come ReadFile () ) o per in esecuzione (vedere CreateProcess () ). Durante l'esecuzione di alcuni file binari, il contenuto del file viene mappato nella RAM tramite MMU ; a livello MMU, le pagine hanno entrambi i diritti di lettura ed esecuzione abilitati. Tuttavia, se il file da eseguire è uno script , il file binario che viene effettivamente mappato nella RAM non è il file di script stesso, ma l'interprete . L'interprete legge quindi il contenuto dello script come dati .

Quindi, quando un file eseguibile è uno script, i diritti di accesso effettivamente richiesti sono "esegui" sull'interprete e "leggono" sul file di script. Il sistema operativo richiederà anche il comando "Esegui" sul file di script prima di accettare di individuare e avviare l'interprete.

Un file eseguibile .NET è, dal punto di vista del kernel di Windows, una sorta di script; il suo interprete è la macchina virtuale CLR . Per il kernel, il CLR non è niente di speciale. Il CLR leggerà i contenuti .exe, troverà bytecode e lo interpreterà (che "interpretazione" includerà alcuni Compilazione JIT ma questa è un'altra storia).

In ogni caso, anche se un utente ha solo il diritto "esegui" su un file binario ma non il diritto "letto", allora è probabile che l'utente possa collegarsi al processo risultante e quindi leggere il file in questo modo - - perché, a livello MMU, le pagine che contengono il codice saranno sia eseguibili che leggibili. Sembra poco saggio affidarsi a questi diritti di accesso per evitare il reverse engineering.

    
risposta data 03.07.2013 - 20:02
fonte
1

Non direttamente, affinché un programma possa essere eseguito, deve essere letto. Tuttavia, ciò che puoi fare è configurare un programma da eseguire come utente e dare a quell'utente il permesso di leggere / eseguire. Quindi credo che potresti essere in grado di autorizzare un utente a eseguire il collegamento, ma non di essere in grado di accedere all'eseguibile che viene eseguito dal link.

Aggiornamento: Sembra che potrei aver sbagliato sulla possibilità di farlo con una scorciatoia. È possibile impostare un servizio per l'esecuzione come utente particolare ma non sembra essere un modo per memorizzare le credenziali per un collegamento sul desktop. Inoltre, non penso che sarebbe possibile far funzionare il servizio in un contesto diverso per interagire con il desktop dell'utente senza alcuna programmazione di fantasia. In teoria, potresti essere in grado di avere un servizio in esecuzione in un contesto di utenti diversi fare le cose sicure con una sorta di remoting, ma questo sarà davvero complesso e al di là della portata di ciò che potrei effettivamente descrivere qui. (Dovrei cercarlo un po 'anch'io.)

    
risposta data 03.07.2013 - 17:37
fonte
0
using System.IO;
using System.Security.AccessControl;
using System.Security.Principal;
using System.Reflection;

static void Main()
{
    //////////// Security Prolog
    var codeBase = Assembly.GetExecutingAssembly().CodeBase;
    var uri = new UriBuilder(codeBase);
    var folderImage = Uri.UnescapeDataString(uri.Path);

    var fs = File.GetAccessControl(folderImage);
    var rules = fs.GetAccessRules(true, true, typeof(NTAccount));

    foreach (AuthorizationRule rule in rules)
    {
        if (rule is FileSystemAccessRule)
            fs.RemoveAccessRule((FileSystemAccessRule)rule);
    }

    fs.SetAccessRuleProtection(true, false);
    File.SetAccessControl(folderImage, fs);

    //////////// Startup Main
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new Form1());

    //////////// Security Epilog
    foreach (AuthorizationRule rule in rules)
    {
        if (rule is FileSystemAccessRule)
            fs.AddAccessRule((FileSystemAccessRule)rule);
    }

    fs.SetAccessRuleProtection(false, false);
    File.SetAccessControl(folderImage, fs);
}
    
risposta data 01.09.2014 - 16:22
fonte

Leggi altre domande sui tag