Diritti di amministratore per un set di codice

1

Sto sviluppando un programma per Windows 7 Enterprise Edition che verrà utilizzato in un ambiente aziendale. L'applicazione correggerà automaticamente determinati errori non appena l'utente seleziona il nome dell'applicazione, sceglie il sintomo o il messaggio di errore e fa clic sul pulsante di correzione.

L'idea alla base è di ridurre la quantità di chiamate che riceviamo presso l'IT Service Desk (il Call Center personale dell'azienda per i problemi IT) e allo stesso tempo assistere l'utente risolvendo il problema entro un minuto (in attesa di il telefono per un massimo di 15 minuti o più).

Non ho ancora il permesso di caricare un'immagine dell'applicazione, ma immagina un piccolo modulo di Windows con 2 colonne, nome dell'applicazione e sintomo. L'utente sceglierà il nome dell'applicazione, farà clic sul messaggio di errore e farà clic sul pulsante FIX. Questo praticamente automatizza tutto ciò che noi tecnici IT faremmo manualmente.

Il problema che sto affrontando è che parte del codice dovrebbe essere eseguita con i diritti di amministratore, ad es. Arresta e avvia un determinato servizio, aggiungendo voci di registro per il computer locale, ecc.

Dato che nessuno degli utenti sarà autorizzato ad avere diritti elevati e il fatto che hanno bisogno di utilizzare questa applicazione come una sorta di alternativa di "auto-aiuto" senza la necessità di chiamare il Service Desk IT, c'è un modo per dare un set di codice "permessi di amministratore"? L'applicazione NON deve richiedere all'utente di inserire QUALSIASI password.

    
posta Willem Voigt 26.09.2014 - 13:57
fonte

2 risposte

2

A quanto ho capito, il modo standard per farlo è creare un servizio che funzioni con diritti di amministratore e che tocchi le chiamate RPC da un'applicazione utente non privilegiata. MSDN chiama questo modello di servizio del sistema operativo . Un'altra opzione è il modello di attività elevato ; di nuovo, vedi MSDN per maggiori dettagli.

Come per qualsiasi software relativo alla sicurezza, non fidarti del client. (In questo caso, "il client" è l'applicazione utente non privilegiata.) Se il servizio o l'attività dell'amministratore accetta comandi come "esegui la procedura di supporto A", probabilmente stai bene. Se il tuo servizio di amministrazione accetta comandi come "avvia servizio arbitrario" o "scrivi chiave di registro arbitraria", un client malintenzionato potrebbe utilizzarlo per avere effettivamente i diritti di amministratore completi.

Elaborare : il client è sotto il controllo dell'utente finale, il che significa che un utente malintenzionato può fare tutto ciò che desidera con esso, inclusa la sostituzione con un client compromesso o modificato che genera problemi qualunque comando vogliano.

Se facendo clic su "NomeApp" "ErrorMessage" "FIX", il client invia una chiamata RPC "Fix AppName ErrorMessage" al server, quindi stai bene. Anche un client malintenzionato non può fare nulla che possa essere un client ben educato.

Supponiamo, tuttavia, che l'interfaccia RPC sia di livello inferiore e che l'elenco delle correzioni sia gestito dal client. Supponiamo che facendo clic su "AppName" "ErrorMessage" "FIX" risulti nel client che dice "So come risolvere il problema. Servizio, scrivere la chiave di registro AppName\A e riavviare il servizio App Service B ." In tal caso, un client mailcious potrebbe dire "Servizio, scrivere la chiave di registro CriticalWindowsSecurityKey\C e riavviare il servizio Evil Hacker Service D ." Sarebbe male.

    
risposta data 26.09.2014 - 14:27
fonte
1

Metti la roba "utile" in un servizio di Windows e installala sui computer dell'utente. Servizi Windows implicitamente esecuzione "elevata".
Usa il tuo metodo di comunicazione cross-process preferito per inviare "richieste" al servizio dal tuo programma di utilità visibile all'utente. (Continuo a preferire l'utilizzo di qualcosa basato su TCP, se non altro perché Windows Security non ha ancora inserito completamente il naso in questi e non desidera che i contesti di sicurezza si mescolino qui). Se sei davvero fortunato, questo potrebbe anche funzionare in remoto, quindi il tuo staff di supporto ha la possibilità di eseguire le cose per conto degli utenti, a condizione che il Servizio sia in esecuzione. Perché due modi per fare la stessa cosa?

Il Servizio può elaborare solo richieste che l'applicazione client visibile all'utente sa chiedere (non non dovrebbe essere un formato libero "ecco un comando DOS; eseguilo" opzione!) ma l'utente non vede o interagisce direttamente con il Servizio; solo il programma di utilità visibile.

Quando è necessario aggiungere la nuova funzionalità, distribuire una nuova versione dell'eseguibile del servizio - OK, in modo faticoso, perché è necessario spegnerlo prima di poter aggiornare il file fisico, ma ancora perfettamente possibile - o distribuire tutte le "funzioni" richieste come Dll che il servizio carica in fase di esecuzione (ricorda solo di includere una "richiesta" per scaricare tutte le "richieste" dll!)

    
risposta data 26.09.2014 - 14:28
fonte

Leggi altre domande sui tag