È sempre stata la mia ideologia che, come utente, puoi fare quello che vuoi su Linux e per tutto il resto, c'è sempre sudo. sudopermette di eseguire poche cose come alcuni altri utenti, il più delle volte casi rootdi amministrazione del sistema. sudoè stata una risorsa di vantaggio maggiore delegare alcuni dei miei compiti e privilegi di routine come utente (root) ad altri e aiutarmi a gestire meglio il mio tempo e altri senza elevare i privilegi oltre ciò che è richiesto. Allo stesso tempo, è la mia fiducia su di loro che mantiene le loro voci presenti insudoersfile di configurazione. Non sono sicuro che possa essere correlato, ma quello che posso dire è che, sudo ti offre una migliore prospettiva di sicurezza di chi tutti e cosa possono fare con i loro privilegi di fiducia. Anche se qualcosa va storto, sono responsabili. (Posso sempre fare qualche subdolo picco con le informazioni di registro sudoers per trovare anche i colpevoli). I miei ragazzi mi hanno sempre espresso la loro preoccupazione per il fatto che devono digitare sudo per tutto ciò che volevano fare con privilegi elevati in ambiente Linux. Qui ho trovato anche la stessa domanda.
Per vedere le soluzioni e la mia ricerca per trovare le alternative, mi sono imbattuto in controlli di accesso basati sulle risorseRBAC ma in un'altra terra avventurosa Solariscon strumenti come pfexececc. Questo approccio è migliore perché questo manterrebbe i privilegi degli utenti già elevati e di cui mi fiderei sulla coscienza e la prontezza di ciò che gli amministratori di sistema vorrebbero fare con i loro privilegi.
Considerando le soluzioni disponibili di RBAC e le sue implementazioni nel mondo Linux, mi sono imbattuto in
SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/
grsecurity http://en.wikipedia.org/wiki/Grsecurity
e mentre ci sono altre implementazioni, le prenderei in considerazione nell'ordine in cima alla lista. L'implementazione di RBAC richiede molto lavoro in un'organizzazione, specialmente quando ci sono molti utenti. L'RBAC suonerebbe una soluzione maggiore in ambienti omogenei. Tuttavia, quando ci sono installazioni Unix eterogenee nella rete e il database utente è comune, ciò potrebbe non riuscire. Poiché SELinux non è scalabile / implementato su Solaris e gli strumenti RBAC / pfexec non sono implementati su Linux. Esistono approcci diversi per fare una sola cosa. Ad esempio: http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto
Installazioni diverse a livello di rete potrebbero non supportare questo approccio (tuttavia openrbac potrebbe essere considerato un approccio di implementazione comune) come sudoers è un approccio host singolo o non è in grado di configurare centralmente la rete / dominio./etc/sudoersdeve essere sincronizzato ogni volta che c'è un cambiamento. Inoltre, durante l'utilizzo del file sudoers è richiesto un knowledge base, è necessario comprendere il linguaggio delle politiche della configurazione dei sudoers per non commettere errori e consentire eventuali sovvenzioni. RBAC può offrire un approccio centralizzato in una certa misura, mentre i profili di sicurezza possono essere comuni, l'aggiunta / rimozione di un utente dal ruolo assegnato può essere eseguita da un unico posto (ovvero il luogo in cui sono archiviate le informazioni utente / passwd / gruppo per il dominio come LDAP, NIS o AD). Ciò richiederebbe implicitamente anche la comprensione dei comandi richiesti per operare sul database RBAC come smexec, smmultiuser, essendo pochi.
Sudo può offrire qui un approccio più multipiattaforma che funziona su tutte le piattaforme Unix / like che offrono le funzionalità setuid. Entrambi sudoe RBACriescono a dare agli utenti non root alcuni privilegi che possono essere fatti senza fornire la rootpassword stessa. Sudo può fornire un approccio più fine / granulare basato sugli argomenti della riga di comando che può essere utilizzato durante l'esecuzione dei comandi e limitare esclusivamente a quale comando con argomenti può essere eseguito con privilegi elevati. Mentre RBAC può limitare l'uso fino ai comandi o ai binari installati ma non avere alcun controllo sugli argomenti della riga di comando. Il controllo è molto meglio e integrato nell'ambiente RBAC mentresudo, dipende dalla configurazione e anche dai vincoli di sicurezza adottati (come non concedere alla shell e in particolare agli host è consentito accedere agli altri host senza problemi). Queste sono solo alcune delle differenze che potrei citare e personalmente ho la tendenza a usare il sudo rispetto all'RBAC, sebbene con queste limitazioni potrei venire a implementare alcune soluzioni. Fino a quando tutti i problemi non verranno risolti da RBAC per migliorare il vantaggio di sudo, non credo che sudo scompaia perché è semplice.