Gli amministratori della sicurezza sono responsabili della tua macchina e di ciò che accade sulla tua macchina. Questa responsabilità viola il modello di sicurezza di base per una macchina Unix a utente singolo perché l'amministratore (una parte assente) è root sul tuo macchina, non lo sei. Unix non è realmente impostato per questo modello.

Gli amministratori devono essere in grado di installare controlli di sicurezza sulla tua macchina per proteggere l'azienda, non solo i dati, la rete e gli altri nodi. Se l'utente locale disponeva dell'accesso root, gli amministratori non hanno più il controllo su tali controlli. Questa è la premessa di base.

Sì, ci sono tantissime ragioni per cui root è necessario per fare cose cattive o per trasformare la macchina in un nodo dannoso e tutte queste sono buone ragioni per non fornire l'accesso come root. E sì, ci sono molti modi per aggirare queste limitazioni e molti modi in cui l'utente locale potrebbe fare cose cattive. Ma alla fine, l'utente locale e il proprietario del rischio non possono competere per il controllo o la responsabilità sulla macchina.

Alcuni motivi che mi vengono in mente:

• L'avvelenamento da ARP o gli attacchi di inondazione di rete sulla rete richiedono generalmente l'accesso root a una macchina sulla rete.

• Essere in grado di installare programmi non autorizzati potrebbe esporre l'azienda a responsabilità legali se tali programmi sono essi stessi illegali (ad esempio perché sono piratati o non concessi in licenza per uso a scopo di lucro o altro).

• Se l'azienda ha un qualsiasi tipo di monitoraggio remoto dei dipendenti (o vuole la possibilità di avere tale monitoraggio anche se non è ancora in atto), dare agli utenti l'accesso root consentirebbe loro per aggirarlo.

• Non avere accesso come root significa che non puoi rm -rf / bin , o qualsiasi altra cosa distruttiva, e né può chiunque abbia accesso ai tuoi dati di accesso, quindi non c'è alcuna possibilità che la tua azienda abbia bisogno di aiutarti a riprenderti da quella situazione.

• Se la tua azienda potrebbe ridistribuire la tua macchina se te ne vai , potrebbero sentirsi più a loro agio nel farlo con fare una completa cancellazione e reinstallazione se non hai mai avuto accesso come root.

• Dare alle persone l'accesso come root è facile, se necessario; rimuovere l'accesso root in modo completo è difficile se diventa necessario.

• Il principio generale del privilegio minimo è che non dovresti concedere a nessuno / a nulla l'accesso non hanno bisogno attivamente.

• Semplicemente non essere passati dai giorni dei server condivisi perché è un processo che ha funzionato e niente ha rotto l'inerzia (l'ipotetico problema di scimmie e scale).

Questa risposta non intende contraddire le risposte esistenti, ma piuttosto integrarle perché è troppo lungo per un commento.

Parte del motivo è (come altri hanno accennato) che gli utenti non possono fidarsi di non fare cose sciocche / dannose. Ma un'altra parte è di chi è la responsabilità di sistemare le cose quando ciò accade?

Sono uno sviluppatore full-stack e devops part-time con accesso root non solo alle mie macchine di sviluppo ma a una parte della nostra produzione server e almeno un certo livello di accesso all'hypervisor su cui sono distribuiti. Ma se sbaglio, sono il partito (o almeno un partito) con le capacità, le competenze e la responsabilità per rimediare. Non così del tipico utente finale: se Bobby l'utente borks la sua installazione di Windows che ha avuto dati mission-critical e / o è stata utilizzata per un lavoro mission critical, allora Bobby non è quello che deve entrare sul suo / il suo giorno libero o lavoro straordinario non pagato per aggiustarlo. Per non parlare della risposta all'ottone come Bobby è riuscito ad affondare la nave quasi da solo.

Quindi parte del motivo per cui i reparti IT limitano i privilegi degli utenti finali è che riduce i propri esposizione al rischio.

AFAIK, ci sono 4 ragioni principali per non concedere l'accesso come amministratore agli utenti standard sui loro desktop:

• proteggere la macchina stessa (non sempre molto efficiente) e le altre macchine sulla rete da possibili attacchi che utilizzano quella macchina come un relay (già coperto da altre risposte)
• proteggere il team di supporto IT da attacchi a livello di amministratore che richiederanno molto lavoro per essere risolto (già coperto da altre risposte)
• mantieni tutte le macchine con (più o meno) la stessa configurazione per essere in grado di eseguire semplicemente distribuzioni remote da una singola macchina di amministrazione: più piccola è la dimensione del team di supporto, meno costoso per il azienda
• impedire (o almeno provare a) agli utenti di installare programmi estranei al proprio lavoro: un utente che gioca ai videogiochi al lavoro o che progetta la sua futura cucina non è molto produttivo ...

Ma non può proteggere i dati sulla macchina né più in generale i dati accessibili all'utente, essere sulla macchina locale o su un server. È qui che i backup vengono in soccorso.

La tua macchina non è utilizzata solo da te. Viene utilizzato anche dal tuo team di supporto desktop.

Se ho accesso root a una casella, in particolare una casella Windows associata a un dominio, posso installare un numero qualsiasi di trucchi diversi che potrei usare per compromettere qualsiasi altro utente la scatola. Supponiamo, ad esempio, un keylogger.

Quindi tutto ciò che devo fare è convincere un tecnico dell'assistenza ad accedere per risolvere un "problema" appena creato (come rompere il segreto condiviso di Kerberos), aspettarlo per passare ad amministratore di dominio e ho appena compromesso l'intera rete.

Il keylogger non verrà rilevato dallo scanner di malware? No, se ho il root non lo farà.

Ottieni ciò di cui hai bisogno per fare il tuo lavoro. Se il tuo lavoro richiede l'accesso come root, lo ottieni, insieme al discorso di potere / responsabilità associato. Il mio lavoro è proteggere tutti gli altri da te.

Se vuoi veramente eseguire il root sulla tua workstation personale, considera il BYOD, ma se lo rompi, lo aggiusti.

L'azienda deve proteggere le cose. Devono proteggere il loro segreto commerciale, ma devono anche proteggere cose come i dati degli utenti. Se ogni dipendente ha un'altra configurazione potenzialmente insicura sul proprio desktop, l'azienda non ha alcuna possibilità di assicurarsi che non si verifichi alcun furto di dati e nessuna perdita di dati. Una gestione centralizzata da parte di professionisti aiuta a mantenere i computer protetti ed evitare la perdita accidentale di dati.

Nel caso di un box unix connesso a qualsiasi tipo di file server NFS della vecchia scuola (v2 o v3), l'accesso root locale consente effettivamente a un utente di interferire con i file di altri utenti, poiché l'autorizzazione è parzialmente implementata lato client con questi protocolli, mentre l'autenticazione è sotto il controllo dell'utente locale in questo modo. Significa che qualcuno può semplicemente fare su un account utente esistente o creato con lo stesso uid e avere accesso ai file appartenenti a quell'uid su NFS.

Inoltre, è "usato solo da un singolo dipendente" il definitivo o il solito modo di lavorare lì? Se le macchine fanno parte di un dominio di autenticazione comune, occasionalmente scambiate tra gli utenti secondo necessità, o l'accesso alle macchine dei colleghi (ma non i loro dati!) È occasionalmente consentito, questo sembra un puro scenario per utente singolo ma in realtà utilizza funzionalità multiutente per la gestione delle apparecchiature scopi.

Da una licenza software POV, non voglio che gli utenti possano installare software volenti o nolenti. Ad esempio, un utente desidera installare Sublime Text, un editor di testo che consente di utilizzarlo gratuitamente per un tempo limitato. Lo rimuove e lo reinstalla dopo il tempo assegnato. Ciò violerebbe l'EULA.