In Windows, se rifiuto la richiesta UAC di un'app, perché non deve continuare a funzionare?

Proveniente da un background Linux / Unix, non riesco a capire come funziona UAC in Windows.

Ho sentito che UAC funziona come sudo. La mia applicazione Linux può fare qualche altro lavoro prima di chiamare sudo.

Ma in Windows, sembra che tutte le applicazioni che richiedono la conferma UAC debbano avere UAC concesso prima di fare qualsiasi lavoro vero e proprio! Eseguo un'applicazione, mi chiede la conferma UAC e la rifiuto - l'applicazione semplicemente non verrà eseguita.

Quindi UAC funziona in questo modo?

sudo su
./run_app

Piuttosto che:

./do_work1
sudo su
./du_work2

Grazie per l'ottima risposta di tutti!

Quando si accede a Windows come utente standard, viene creata una sessione di accesso e viene assegnato un token contenente solo i privilegi di base. In questo modo, la nuova sessione di accesso non è in grado di apportare modifiche che potrebbero influire sull'intero sistema. Quando si accede come utente nel gruppo Administrators, vengono assegnati due token separati. Il primo token contiene tutti i privilegi in genere assegnati a un amministratore e il secondo è un token limitato simile a quello che riceverebbe un utente standard. Le applicazioni utente, inclusa la shell di Windows, vengono quindi avviate con il token limitato, risultando in un ambiente con privilegi ridotti anche con un account amministratore. Quando un'applicazione richiede privilegi più alti o si fa clic su "Esegui come amministratore", l'UAC richiederà la conferma e, se viene fornito il consenso,

Da quello che ho capito, ciò che significa l'ultima frase è che o la finestra di dialogo UAC viene visualizzata prima che l'app venga caricata in modo che venga avviata con il token senza restrizioni, oppure se viene avviata con privilegi utente standard e necessita di privilegi elevati nel mezzo per alcuni funziona, deve ottenere il consenso dell'utente e quindi generare un nuovo processo che viene eseguito con diritti elevati . Il token assegnato all'avvio di un processo è ciò che determina i suoi diritti. Questo token non può essere modificato in un secondo momento, quindi se sono richiesti più diritti, deve essere generato un nuovo processo.

In questo modo, UAC non è esattamente uguale a sudo .

In Windows, il prompt UAC viene attivato quando si tenta di eseguire un eseguibile contrassegnato come richiedente elevazione in un manifest incorporato nel file e non si esegue già l'elevazione. Il comportamento è più simile a setuid che a su in quanto è il file, non il comando che dice al sistema operativo che l'eseguibile deve essere eseguito con credenziali diverse.

È perché sono diversi, chiari e semplici. Controllo dell'account utente avrebbe potuto essere implementato come sudo, ma non lo era.

Puoi pensarlo come un'analogia con la protezione della rete.

sudoè come quando un programma richiede l'accesso alla rete e il firewall richiede di concederlo o meno. Puoi dire di sì e il programma aprirà il socket, oppure puoi dire di no e si lamenterà della mancanza di connessione e farà tutto ciò che può fare senza accesso alla rete (alcuni programmi mal progettati in realtà si bloccano). Per esempio:

function1();
input();
function2();
secure_operation(); //requests access
function3();        //may depend on results of previous operation; error-checking important

Controllo dell'account utente è più simile all'avviso che viene visualizzato quando si tenta di aprire un file scaricato in un volume NTFS. Windows ti avvisa del potenziale male e ti chiede se vuoi eseguirlo (per niente) o no. È un'operazione tutto o niente; non puoi scegliere di fidarti solo di una parte del programma e non di altri. Per esempio:

if (requires_high_priv(program)) {
  if (request_priv(program))
    program();
}
else {
  program();
}

Dovete ricordare che, diversamente da Linux, che è più orientato verso utenti e applicazioni avanzati, Windows è progettato per essere user-friendly per il maggior numero possibile di utenti, quindi semplificare la sicurezza è fondamentale. Inoltre, a causa della sua ampia superficie di esposizione, è un bersaglio frequente per i malware, quindi ha più senso fidarsi completamente di un programma o non farlo affatto.

Non conosco a fondo l'architettura linux, quindi perdonami se commetto un errore, ma la mia comprensione è che Linux e Windows non sono affatto così diversi in questo senso ...

Un esempio ... Uno script di copia che esegue una copia di un file normale in una posizione non protetta e un file che tenta di copiare in una posizione protetta, quindi di nuovo una copia normale.

La mia comprensione è che in Linux un'applicazione viene semplicemente eseguita e ha tentato di eseguire un'azione - se non ha il permesso di fare quell'azione - fallirà quell'azione, ma continuerà. Nell'esempio sopra - quando esegue lo script di copia in Linux come utente normale, copierà il file normale, darà un problema di autorizzazione e copierà il secondo file - se eseguito con sudo, farà tutte e tre le copie.

Windows è esattamente lo stesso a questo proposito: l'esecuzione dello script come utente non amministrativo ne copia semplicemente uno, l'autorizzazione emette il secondo e copia il successivo. Con UAC, eseguirà tutti e tre.

La differenza è che molte applicazioni Windows hanno semplicemente un set di configurazione in modo che chiedano l'elevazione del controllo dell'account utente per impostazione predefinita e si chiudano / falliscano se non ce l'hanno .... ma, questo sta diventando molto meno.