Una delle prime cose che ho notato la prima volta che usai Ubuntu (ottobre 2004) fu che l’installer non mi chiese di inserire una password per l’account root. Che stupido, pensai, si vede che non sono abbastanza umano:
…io sudo, e voi?
La cosa stupisce sempre per i primi cinque minuti, poi sono stato folgorato e sono diventato un “essere umano che usa Linux” anche io :) Vi spiego perché (e come) potreste voler usare sudo, a prescindere dalla distribuzione che utilizziate.
Chiariamo: sudo non è un’invenzione di Ubuntu: diciamo che l’uso di sudo è stato reso popolare da Ubuntu, e nel suo piccolo, da MacOSX.
I. Presentazione
In realtà sudo è uno dei software più usati e più conosciuti dagli amministratori di sistema, principalmente per la facilità, la sicurezza e l’infinita flessibilità con cui può essere usato per attribuire privilegi “mirati” ad alcuni utenti o gruppi.
Sudo è facile e “naturale”
Non c’è poi tanto bisogno di spiegare questo concetto… La suddivisione schizofrenica tra utente normale e superutente è un classico dei flame contro unix, e se si dimostra una scelta saggia in alcuni ambiti, non lo è di certo per un sistema moderno e adatto ai mille diversi usi come sta diventando Linux, anche grazie a sudo. Non ha alcun senso dover usare due password differenti, specie se si è l’unica persona ad usare il sistema.
Chi ha un po’ di esperienza con il pinguino avrà notato che aiutando qualche novellino capita spesso di dover spiegare il concetto astruso di superutente, e doversi districare tra mille terminologie e fargli capire che se deve usare il PC “normalmente” allora è vietato essere superutenti, al contrario se si deve configurare o compiere azioni di amministrazione bisogna essere superutente ma mai connettersi a internet come superutente perché è pericoloso… bla bla bla
…senza contare chi taglia la testa al toro e si logga direttamente in GNOME come root :D
Sudo è sicuro
Invece di tutte le schizofrenie e le complicazioni perverse appena accennate, sudo è la maniera più naturale di proteggere il proprio sistema da sbagli, errori e incongruenze… e il tutto in completa sicurezza.
Al momento dell’installazione di un sistema che fa uso di sudo, come ad esempio Ubuntu, il primo (e solo il primo) utente creato ha automaticamente i privilegi di amministrazione e può usufruirne solo dopo aver inserito la propria password.
Mentre un sistema tradizionale avrà sempre un utente root come “bersaglio fisso”, in un sistema che fa uso di sudo non ci sarà mai un unico superutente, e un eventuale attacco avrebbe la complicazione aggiuntiva di dover capire quale utente attaccare ;)
Altro motivo per cui sudo è sicuro è che nei log di sistema le azioni compiute non risalgono sempre al solito “root” ma sono differenziati per utente. Questo rende più semplice risalire a chi ha fatto cosa, in qualsiasi momento.
Sudo è flessibile
La flessibilità di sudo è quella che lo fa apprezzare agli utenti più smaliziati: se amministrate un sistema al quale accedono diversi utenti, potete decidere esattamente certi compiti da permettere a certi utenti. Il tutto è gestito tramite un unico file, che – come misura di sicurezza aggiuntiva – non va mai modificato direttamente.
Ammettiamo di avere un certo numero di utenti che hanno un account sul nostro server. Vogliamo permettere all’utente torvalds di aggiornare il sistema via apt-get, perché ad esempio ci fidiamo di lui; allo stesso modo vogliamo permettere a tutti gli utenti che sono nel gruppo sexygirls di poter connettersi a internet tramite il comando pon. Vogliamo inolte che questi utenti non possano compiere nessuna ulteriore attività per cui siano richiesti privilegi di amministrazione…
Con sudo tutto ciò è prassi, ed è di una semplicità estrema.
II. Installazione e utilizzo
Installiamo e abilitiamo sudo
Installare sudo è di una facilità estrema: visto che è uno dei pacchetti più diffusi e apprezzati lo trovate già incluso nei repository di ogni distro esistente, a volte è anche installato e già pronto all’uso, come ad esempio in Fedora. Quindi per l’installazione avvaletevi dei sistemi offerti dalla vostra distribuzione.
Abilitare sudo è anch’essa un’operazione molto semplice, basta impostare alcuni utenti nel file “sudoers”. Per farlo bisogna essere root e dare il comando:
#: visudo
A questo punto potrete aggiungere il vostro nome utente e dargli pieni poteri, così:
felipe ALL=(ALL) ALL
Questo renderà l’utente felipe come l’equivalente del tradizionale “root”. Passiamo agli esempi di prima, ecco come dovrebbero venire impostati:
torvalds ALL= /usr/bin/apt-get %sexygirls ALL= /usr/sbin/pon
Per i dettagli (ce ne sono tanti) vi rimando alla documentazione. Esiste perfino la possibilità di garantire privilegi senza dover inserire una password (non consigliato!). Sappiate solo che il 99% dei normali casi d’uso è già soddisfatto dalla prima linea in cui garantisco pieni poteri al mio utente :)
Completiamo l’opera: disabilitiamo root!
Proviamo subito se sudo funziona, con qualcosa di tosto :) Perché il processo sia completo non ci resta che disabilitare sto famoso superutente root. Non cancelleremo l’utente, ci limiteremo a disabilitarlo, così:
$: sudo passwd -l root
A questo punto dovrebbe bussare alla vostra porta una persona molto attraente e completamente nuda, eccetto un vassoio con un Martini per festeggiare. Voi accettate.
Se non voleste festeggiare o vi passasse la voglia, sappiate che potete tornare indietro in qualsiasi momento, e riabilitare l’utente root con il comando:
$: sudo passwd root
Che vi chiederà di inserire una nuova password per riabilitare root.
Caccia alle streghe: i falsi miti di sudo
Ci sono alcuni falsi miti, prodotto di semplice ignoranza in materia, che bisogna cacciare ed eliminare. Sia ben chiaro però, che noi siamo decisamente favorevoli a tutte le fantastiche streghe che popolano la terra :)
* Sudo non è sicuro quanto root
Semplicemente falso, sudo è sicuro allo stessa stregua di una configurazione più classica con root/resto di utenti, anzi è più sicuro per certi versi.
* Ma se tutti gli utenti possono usare sudo, dov’è la sicurezza?
Un classico… sudo è abilitato solo per il primo utente creato sul sistema, generalmente è chi installa. Poi se si vuole si può estendere il privilegio ad altri, ma all’inizio non hanno accesso a sudo.
* Con sudo devo mettere la password ogni volta
No, sudo tiene la password in memoria per cinque minuti
* E se voglio tenere la password più alungo?
È sempre possibile iniziare una “sessione sudo” con il comando “sudo -s”
* Ma io sono abituato a scrivere “su”!
Non c’è problema, crea un alias nel tuo bashrc, così:
$: echo "alias su='sudo -s'" >> ~/.bashrc
e fai il logout/login per caricare le nuove impostazioni
uhm non motivi chiaramente perche’ sudo e’ sicuro quanto root. Io ho sempre usato il classico sistema su, e tutto il possibile gira con il mio utente comune. Indubbia la praticita’ di sudo, ma se per una qualche falla in
browser
client di posta
client irc
bla bla
il mio utente comune offre accesso alla sua home a terzi, nel caso di sudo il malintenzionato non ha molto da tribolare per ottenere il sistema e metter un rootkit!
Che ne dici?
Dopo aver provato Ubuntu per qualche mese, al mio ritorno su Debian la prima cosa che ho fatto è stata proprio l’abilitazione di sudo e la disabilitazione dell’utente di root.
L’unico problema però era dato dal fatto che tutti i software di amministrazione presenti nel menu di Gnome (lanciati con gksu) richiedevano la password di root. Per ovviare a questo ho trovato questo metodo:
– avviare gconf-editor
– abilitare l’opzione /apps/gksu/sudo-mode
spero che questo suggerimento possa essere utile a qualcuno ;)
Ammetto che la prima volta che ho installato Ubuntu dopo anni che non provato linux (credo una redhat 5 qualcosa) ho passato i primi 5 minuti a invocare tutto il calendario perchè non capivo quando mi fossi perso l’inserimento della pwd di root :D
Bella spiegazione, come sempre.
@zippole:
per quanto riguarda la sicurezza di sudo, considera il fatto che se fosse attivo l’utente root, a un malintenzionato basterebbe venire a conoscenza unicamente della password di quest’ultimo (il nome utente lo conosce già, è “root” :) ).
Utilizzando sudo invece il malintenzionato deve venire a conoscenza anche del nome utente (e sperare tra l’altro che il nome utente trovato abbia privilegi sufficienti a fare i danni voluti, visto che sudo permette anche di dare privilegi solo per alcuni comandi).
Per quanto riguarda quello che tu dici (la possibile falla), ricorda che in ogni caso il malintenzionato deve venire a conoscenza della password dell’utente, perché al primo avvio di sudo gli verrebbe richiesta.
sudo…insopportabile!! lo odio, preferisco decisamente il classico su.
qual’è la differenza tra
sudo -s
e
sudo -i
??
io ho sempre utilizzato il secondo comando per avere una shell per root, mentre qui viene indicato il primo comando…
Io di solito faccio
sudo bash
quando devo modificare tante cose. Però non so se è un uso ortodosso.
allora sudo -s è inferiore a sudo -i, con sudo -s logghi come l’utente target ma senza impostare le variabili d’ambiente, invece con sudo -s imposta le variabili d’ambiente dell’utente target.
In generale basta sudo -s.
per dirla ancora di più alla carlona, con sudo -i effettui un login con l’utente target a tutti gli effetti.
Io invece uso “sudo su -” XD
Diciamo che non c’è la retta via…..tutte le vie portano a dio (in questo caso l’amministratore) XD
* Con sudo devo mettere la password ogni 5 minuti
…Si
Quando ho installato Ubuntu sul portatile la prima cosa che ho fatto e’ rimettere la password a root :)
1) Sudo non è facile, nè naturale (almeno non per tutti)…
Ci sono persone (e io sono tra questi) che trovano la distinzione utente normale/root logica e ineccepibile… Non è un concetto tanto difficile, poi…
2) Sudo non è sicuro.
Io scelgo una password umana (sui 10 caratteri, +o- casuali) per l’utente normale, in modo da poter accedere con facilità al mio account, e scelgo una password più difficile per l’utente root. Con il sistema usato da Ubuntu la password dell’account normale è anche quella di root… E la password dell’account normale è in genere più semplice, e comunque è più esposta a rischi. Per esempio un collega che mi spia la password adesso (con la mia fiammante openSUSE) avrebbe solo quella del mio account, con il sistema sudo avrebbe la password dell’intero sistema!
E quando nella mia openSUSE mi loggo (come root o come utente normale), tutto viene salvato nel file , come in ogni distro che si rispetti, quindi il discorso dei file di log non lo condivido più di tanto (o meglio non lo condivido per niente)…
2a) Per quanto riguarda poi gli attacchi che non possono essere mirati all’utente root, anche qui noto una certa imprecisione…
Praticamente oggi il 90% degli attacchi informatici via Internet si basano su buffer overflow da remoto… Se io uso un exploit con dentro un bellissimo shellcode, questo mi apre una shell che gira con gli stessi privilegi del demone del servizio attaccato… Indovina che privilegi? (suggerimento: il 90% dei demoni hanno privilegi di root)
3) Sudo non è flessibile… Citi l’esempio di un sistema multiutente… Se in ambito desktop forse sudo potrebbe andare bene, in ambito server (o cmq sistema multiutente) non me lo vedo proprio… E’ proprio qui che la differenza tra amministratore e comune mortale è più netta e marcata… E infatti in ambito server nessuno ha ancora proposto questo sistema…
4) Conclusioni:
Per chi volesse togliere l’odioso (IMHO) sudo ci dovrebbero essere le istruzioni su “man sudo_root”
@VeeJ:
Ottima segnalazione, grazie!
@diavolo rosso
con sudo su – snaturi su, non è la retta via assolutamente quella che hai proposto, tutto il contrario.
@zak
la sicurezza con sudo dipende dal tipo di server che devi metter su. Cmq sì, in generale non è indicato per i server…anche se in generale dipende dai tipi di servizi. Poi nessun sistema è sicuro a priori. Di certo è più difficile sgamare quale è il vero account di amministrazione su 10 account comuni che puntare direttamente a root.
Poi gli attacchi di buffer overflow di solito beccano servizi specifici, sta al sistemista cercare di complicare le acque. Poi Dio benedica gli aggiornamenti di sicurezza :P
@zakk: io non capisco perche dici che in ambito multiutente sudo non va bene.
Facciamo finta che tu sei l’amministratore di rete, e la tua azienda per non caricarti di lavoro, si affida a un consulente per gestire un servizio temporaneo sulla macchina server. Questo tizio ha necessità di modificare dei file di configurazione che stanno in /etc in /usr o dove ti pare a te, in ogni caso fuori dalla sua home. a sto punto che fai? gli dai la password di root? oppure cambi i privilegi sui file di mezza macchina per farlo lavorare?
invece con sudo metti il suo utente nel sudoers e gli fai usare nano con i privilegi di root e quando il consulente ha finito e se ne torna a casina sua, lo elimini dal sudoers e felici come prima.
Io continuo a non capire se è ignoranza o pigrizia di scrivere la password ogni volta
@Diavolo_Rosso: Hai fatto un esempio veramente pessimo, fatico a trovarne di peggiori :-)
Se fai usare nano con privilegi di root a uno, tanto vale dargli l’accesso a tutto il sistema!
Visto che tanto gli bastera scrivere:
$ nano /etc/passwd
per crearsi il suo account con privilegi di root!
e i log cosa li hanno inventati a fare? -_-
@Diavolo_rosso: ma usare i group no ?
e cosa cambia? devi andare cmq a modificare i privilegi dei file perche al 90% i privilegi dati al gruppo sono diversi di quelli dati all’owner
@DierRE: nascondere l’account root tra 10 utenti normali è un classico esempio di “security through abscurity”, che (non lo dico io ma eminenti esperti di sicurezza) non hai mai funzionato più di tanto…
Sono d’accordo che aggiunge un ulteriore incognita per l’attaccante, ma quanto sei loggato su una macchina (e se hai una lista di utenti con tutta probabilità lo sei), scoprire chi è l’amministratore è a un “ps aux” da te :-)
(basta guardare chi degli utenti dà comandi “da amministratore”)
@tutti:
Noto un po’ di nervosismo… C’è qualche motivo in particolare? Ho sbagliato a scrivere di sudo? Non credevo che ci si potesse offendere per questioni così neutre…
Mi riferisco al solito… Se non volete essere moderati (e adesso sfoltisco un po’ di messaggi stupidi) cercate di argomentare, non offendete e cercate di accettare che non siamo in uno stadio.
Grazie
L’amministratore UNIX secondo >
Io do il computer aziendale di cui sono amministratore in mano a terzi. So che potrebbe ottenere privilegi di root con due righe di comando.
Magari questo mi mette su una botnet o mi trafuga segreti aziendali, o si frega i numeri di carta di credito dei clienti dell’azienda per cui lavoro…
Tanto poi vado a vedere i log, sono furbo io… (mentre il l’altro scappa con i soldi)
MA STIAMO SCHERZANDO?!?
dopo secondo nel post precedete manca Diavolo_Rosso
(se l’è mangiato wordpress)
Anche io sono rimasto un pò basito quando, lasciando opensuse, ho scoperto che il primo utente configurato nel sistema (e per uso desktop quasi sempre l’unico) è praticamente root. Senza contare che come faceva notare qualcuno normalmente nessuno si complica la vita in password impossibili se non costretto.
La mia idea quindi si puo riassumere in alcuni punti:
1) non so giudicare in maniera assoluta se l’account root abilitato è _sempre_ un soluzione migliore di un esclusivo uso di sudo; secondo me dipende dai casi e dalle esigenze
2) Durante la creazione della password per il primo utente ubuntu quanto meno dovrebbero impostare alcune limitazioni (lunghezza, caratteri numerici e caratteri maiuscoli) visto che alla fine è la password di root
3) L’installazione standard di ubuntu dovrebbe avere un file sudoers più articolato ovvero non abilitare il primo utente a fare tutto come root ma solo alcune operazioni fondamentali (tipo gestione degli aggiornamenti e al limite l’uso di un editor di testo); il resto delle operazioni più comuni potrebbe essere già presente per comodità ma commentato.
4)sicurezza * semplicità = k
beh non è nenache molto furbo mettere i dati sensibili dei clienti sulla macchina server affacciata su internet -_-
io ho fatto un semplice esempio, che era il primo che mi è saltato per la mente. Non c’è bisogno di inventarsi che i consulenti vengono presi a san vittore.
Al posto di nano ci vogliamo mettere uno script in bash che richiama nano solo sui file che interessano al nostro ergastolano? il discorso non cambia. rimane il fatto che bisogna modificare una riga del sudoers contro la configurazione di decine di file. rimane sempre lavoro in meno
@Diavolo_Rosso: Nessuno ha detto che la macchina è affacciata su Internet…
Cmq lo script posso benissimo farlo chiamare da un eseguibile setuid con privilegi di esecuzione solo per un gruppo creato ad hoc per l’amministratore-ergastolano… stessi risultati, senza sudo…
E comunque sappi che quando si parla di sicurezza è sempre meglio essere paranoici, e pensare che la persona alla quale affidiamo il nostro sistema potrebbe essere appena uscita di cella… Non si sa mai!!!
@diavolo_rosso
“beh non è nenache molto furbo mettere i dati sensibili dei clienti sulla macchina server affacciata su internet -_-”
bè.. pensa ai servizi via web.. da qualche parte li dovrai pur mettere…
La sicurezza dei dati è a prenscindere da dove vanno messi, tenendo sempre presente che è sempre meglio esporne il meno possibile. Pensa a una web application tipo opengroupware o corporate portal e immagina che attraverso un cgi mal scritto in si riesca ad avere accesso non privilegiato alla macchina: che differenza fa _dove_ hai messo i dati?
@felipe
hai mai pensato di aprire un #pollycoke su freenode? A volte questo spazio è limitante per questo tipo di discussioni e sicuramente non saresti costretto a moderare i messaggi qua dentro…
@iencosaracino:
uhm no, ho sempre pensato che i commenti, se usati bene, fossero più che sufficienti…
@zakk:
avrai notato che evito di rivolgermi a te direttamente da tanto tempo, visto che hai l’offesa gratuita facile.
noto che sei spesso qui e commenti praticamente tutto il commentabile, potrei chiederti di auto-moderarti? commenta ma non prenderla come fatti personali. non mi va di fare la parte del poliziotto ma tu continui a comportarti in maniera strana e sicuramente esagerata rispetto alle stronzate di cui si discute qui.
se sei qui vorrà dire che un minimo questo posto ti piace, no? potresti allora cercare di mantenerlo un posto piacevole, per favore?
Grazie.
quando ho fatto l’esempio avevo in mente un esempio del tipo server web che temporaneamente deve mettere su un servizio di newsletter. ma visto che state buttando dentro tutte queste complicazioni rispondo lo stesso quasi per sfida :P
Io i dati sensibili li sposterei su una bancadati esterna alla zona demilitarizzata con un apposito programmino che si autentifichi alla macchina, in modo da non lasciare troppo a lungo dei dati sensibili su una macchina potenzialmente a rischio.
Anche se qualcuno si infiltrasse nel server, prima di avere accesso alla banca dati, dovrebbe capire dove quando e perche i dati sono spostati e anche se lo capisce, dovrebbe capire anche il metodo che usa il programma per autentificarsi alla banca dati. a quel punto e bello che scoperto e denunciato.
@diavolo_rosso
mi spiace entrare in polemica con te, non la prendere come fatto personale.
Non credo che la tua soluzione sia gestibile (sopratutto se utilizzi software terzi) ed in ogni caso siamo sempre li, intanto qualcuno ha i tuoi dati, se poi qualcuno si accorge che il sistema è stato violato allora dopo parte la denuncia.
Il fatto che metti un programmino che si autentichi verso la banca dati (la prendo per buona ma non ho ben chiaro come) vuol dire due cose:
1) il tuo programmino ha un comportamento trasparente verso le applicazioni web, quindi il cracker di turno non ci mette molto a sgamarlo.
2) il tuo programmino non ha un comportamento trasparente verso le web app quindi le web app non funzionano a meno che non vengano riscritte.
Normalmente i dati rubati attraverso web app sfruttano i bachi delle web app stesse quindi normalmente noti operazioni strane nei log delle tue app attraverso i quali risali all’ip dell’attaccante:
immagina questo scenario:
pc_attaccantepc_win_zombieproxy_cineseproxy_iraniano….server_vittima
pensi che qualcuno possa mai risalire all’identità dell’attaccante?
Allora molto meglio essere paranoici sul serio e inserire dei protezioni attive nel tuo sistema (IDS) che al primo tentativo di operazione “strana” interrompe il servizio come meglio può.
Non sempre è possibile e raramente è semplice.
In ogni caso non credo di continuerò questa discussione (peraltro interessante) qua perchè non è il posto migliore per farci (alla fine) i fatti nostri. Anzi chiedo scusa a felipe per aver abusato del suo spazio: un #pollycoke cmq non ci starebbe male…
@iencosaracino:
Ma figurati, qualsiasi discussione attinente invece è molto interessante, specie se portata avanti con questi toni civili e normali :)
Anzi comincio ad appassionarmi anche io alla “vicenda” :D
@zakk:
zakk è ovvio che se poi un utente ha permessi di superuser deve usarlo come tale, per esempio non una password farlocca ma una seria. Poi, anche se io non sono un espertone nel campo attacchi cracker, so usare un pò giusto backtrack, ora mi sono appena fatto un ps aux sul mio serverino casalingo, tra mysql, apache etc.. non c’è un processo che non sia affidato ad un utente per fatti suoi (apache a www-data, mysql-server a mysql e così via). Dipende da uno come fa le cose, ma aprirsi una shell non fa di te automaticamente l’amministratore di sistema. Poi da quello che so io, entrato nel sistema, le password o le sgami sniffando connessioni non protette o ti dai al decriptaggio, che cmq non sono entrambe immediate come cose.
Poi certo, se fai avviare a root oppure al tuo utente amministratore tutti i processi meriti di essere attaccato :D
che poi ripensavo anche ad un altra cosa, prima di poter avere accesso deve accedere cmq al server cercando di capire cos’ha che puoi attaccare, e già con IDS si risolve qualcosa.
Boh…secondo me sudo non è poi così banale come soluzione, ma lo dico da profano, io stesso sul debian server ho evitato di metterlo.
Bu io uso sudo da un po …. messo su fedora prima e poi con ubuntu trovato di default.
Nessuna paranoia di sicurezza, il mio e’ un desktop. Sui server non tengo sudo perche’ lo trovo piu’ scomodo, semplicemente impedisco l’accesso a root diretto da ssh o simili e poi vado di su – root per le 4 operazioni di manutenzione.
Parlare di sicurezza e’ un discorso molto variegato, ci son argomentazioni oggettive e convinzioni personali, io ad esempio non darei mail l’account di root del server documentale aziendale ad un consulente :)
Tonando in tema , certo e’ che non sarebbe male avere un RBAC funzionante pianamente su linux :)
Vorrei dissentire con chi dice che sudo non è adatto ai server. Direi, anzi, che è più adatto ai server che ai desktop.
La ragione è perché, tramite sudo, si possono concedere ad un utente standard i privilegi di superutente solo per compiti specifici, SENZA che l’utente in questione debba conoscere la password di root. Il punto focale è proprio questo: concedere a terzi alcuni dei privilegi del superutente (per comodità o anche per necessità) senza dover spifferare la password di root a nessuno (meno persone la sanno, meglio è per la sicurezza).
Inoltre, l’uso di sudo non implica affatto la disabilitazione dell’utente root: Ubuntu, secondo me, non usa sudo al meglio. Di fatto è come avere un utente amministrazione uguale a root ma con un nome diverso, con in più la scocciatura di dover inserire la password ogni 5 minuti.
D’altra parte, vista la vocazione decisamente Desktop di Ubuntu, una eccessiva complicazione dell’infrastruttura amministrativa può essere meno desiderabile che altrove. Il discorso dovrebbe essere diverso per Ubuntu server…
@tutti quelli dei 5 minuti
i 5 minuti di sudo sono l’opzione di default. nessuno vieta di impostare il ticket della sessione a 30 minuti o a 5 ore…
Non ho letto tutti i commenti ma concordo con gpz500.
Sudo non serve a trasformare un utente semplice in root! sudo esiste perchè l’amministratore del sistema possa concedere dei privilegi spesso temporanei e mirati a un utente semplice. Ubuntu secondo me ha fatto una scelta sbagliata nel disabilitare root assumendo che l’utente medio è troppo stupido per capire uno dei concetti cardine del mondo unix. Penso che questo sia anche un pò offensivo e che utenti che non sono pronti ad accettare la diversità di unix rispetto a quello a cui sono abituati tanto vale che unix non lo usino.
Se poi a uno piace sudo può benissimo imparare ad usarlo e configurarselo da sè senza che sia la distribuzione a imporlo.
Secondo me ubuntu avrebbe dovuto lasciare root abilitato e magari consigliare l’uso di sudo al momento dell’installazione spiegandone le motivazioni.
Questa moda di considerare gli utenti stupidi non farà che abbassare il livello degli utenti che usano linux e non so quanto questo possa essere positivo..
@iencosaracino
Io sto criticando proprio la scelta di default che è stata fatta in Ubuntu: è chiaro che l’utente capace può configurare tutto come vuole, anche riabilitare l’utente root…
Ripensandoci, il default di Ubuntu un motivo ce l’ha: evita di doversi ricordare due password diverse (una per l’ordinario login e l’altra per compiti di amministrazione), ma non so se è un motivo sufficiente per la scelta che è stata fatta.
@felipe: se per comportamento strano intendi che non sono sempre d’accordo con quello che scrivi, allora sì il mio comportamento è strano (anche rispetto anche alla media del blog)…
però stai attento che se mandi via (o chiedi di auto-moderarsi) a tutte le persone che non la pensano come te questo blog ne perderà…
Diventerà tutto un dire “bravo, felipe”, “che figata felipe”, “avanti così felipe”…
Per quanto mi riguarda questo probabilmente sarà il mio ultimo post…
Ciao a tutti.
P.S.: guarda il commento numero 12: sono stato il più politically correct possibile… Tutto pieno di IMHO, “secondo me”, “io ritengo che”…
Logico che se scrivi delle gran cacchiate prima o poi qualcuno te lo farà notare. Ciao!
Trovo interessante la discussione che è scaturita dall’articolo su sudo, ma credo che si ci sia del torto di fondo.
Cerco di spiegarmi meglio al fine di evitare polemiche non volute.
Non uso Ubuntu, ma mi pare di aver compreso che lo scopo principare questa distribuzione sia di dare un sistema linux gestibile e fruibile da tutti (parliamo delle esigenze dei un utente normale, non quelle di un’appassionato o “smanettone”) e quindi ritengo che il tipo di “educazione” che fornisce (separazione forzata dei privilegi) sia già un grosso passo avanti per istruire una classe di persone che probabilmente non ha nemmeno ben chiara la differenza tra root e gli altri utenti (A maggior ragione se qualcuno proviene da Windows, dove l’utente di default deve quasi per forza essere Amministratore).
Lungi da me il criticare le vostre considerazioni, ne sapete di certo più di me, ma non mi pare di aver letto di nessuno che abbia considerato sudo come uno strumento educativo.
Se poi si vuole discutere di sudo in se come strumento di amministrazione, slegandolo dal contesto Ubuntu… Beh allora non considerate per favore il mio intervento e scusate :)
Trovo interessante la discussione che è scaturita dall’articolo su sudo, ma credo che si ci sia del torto di fondo.
Cerco di spiegarmi meglio al fine di evitare polemiche non volute.
Non uso Ubuntu, ma mi pare di aver compreso che lo scopo principare questa distribuzione sia di dare un sistema linux gestibile e fruibile da tutti (parliamo delle esigenze dei un utente normale, non quelle di un’appassionato o “smanettone”) e quindi ritengo che il tipo di “educazione” che fornisce (separazione forzata dei privilegi) sia già un grosso passo avanti per educare una classe di persone che probabilmente non ha nemmeno ben chiara la differenza tra root e gli altri utenti (A maggior ragione se qualcuno proviene da Windows, dove l’utente di default deve quasi per forza essere amministratore).
Lungi da me il criticare le vostre considerazioni, ne sapete di certo più di me, ma non mi pare di aver letto di nessuno che abbia considerato sudo come uno “strumento educativo”.
Se poi si vuole discutere di sudo in se come strumento di amministrazione, slegandolo dal contesto Ubuntu…
Beh allora non considerate per favore il mio intervento e scusate :)
@diavolo_rosso
.. server web che temporaneamente deve mettere su un servizio di newsletter. ma visto che state buttando …
perchè il webserver gira come root?
e i log cosa li hanno inventati a fare? -_-
se sono root con i log posso fare quello che mi pare tipo cancellare,modificare ma soprattutto disabilitare il servizio che li gestice.
@Anonimo
“perchè il webserver gira come root?”
ho mai detto che il webserver gira come root? ho detto che ci sono da modificare dei file di configurazione e fino a prova contraria per scrivere in /etc bisogna avere privilegi di root.
“se sono root con i log posso fare quello che mi pare tipo cancellare,modificare ma soprattutto disabilitare il servizio che li gestice.”
Sudo non ti fa diventare root e io non ho mai detto di usare sudo per dare i massimi poteri. Hai i privilegi di root solo su nano, quindi ci può stare che cancelli i log ma non disabiliti e abiliti niente. e cmq un buon amministratore di rete, tiene monitorati i log, soprattutto se ci possono mettere mano + persone.
fare
su – root
comando
oppure
sudo – comando
dal punto di vista della sicurezza sono la stessa cosa: entrabi usano root.
Tutti i manuali di sicurezza indicano l’eliminazione di sudo tra i primi passi da compiere nell’attivitò di hardening.
Il fatto che ubuntu utilizzi il sudo come strumento amministrativo d’eccellenza e che presupponga che l’utente indicato in installazione sia abilitato nel sudoers a fare tutto si giustifica solo con fatto che ubuntu si propone come ambiente desktop e meno come server.
Il fatto di avere un utente, diverso da root, che possa fare sudo ed utilizzi la sua stessa password equivale, dal punto di vista della sicurezza, ad indicare in installazione una password di root. Non ho capito da cosa scaturisca questa scelta, francamente.
Comunque,la prima cosa faccio dopo l’installazione di Ubuntu (sia per server, che per desktop) su macchine usate per lavoro (e non mie) è un bel
sudo passwd
per abilitare la password di root, ed eliminio dal sudoers ogni utente, se la situazione me lo consente.
Se poi c’e’ l’esigenza di lanciare da root qualche comando, abilito il singolo comando in sudoers. E se c’e’ da lanciare una script, la scrivo con utente root con accesso rwx-r-x-r-x su cartella rwx-r-x-r-x.
@felipe
non ho mai fatto id utenteinstallazione per verificare se è id=0, mi auguro che ubuntu non faccia anche l’errore di definire utenti pari a root.
Fantastico. Mi hai chiarito definitivamente il problema. Con linux ho iniziato con il live cd di slax, quindi il problema (root/toor) non si poneva. Poi sono capitato direttamente su ubuntu e dal primo momento ho capito l’importanza di sudare (… ma non puzzo, come dice un mio amico).
Grazie per aver esteso a noi poveri sudoers le preziose infoZ, così quando qualcuno mi chiederà a cosa serve sudare avrò un bel link da mandargli.
;)
Tagliamo la testa al toro :
(tratto dalla “Ubuntu Bible” gratuita e scaricabile in PDF:
http://www.downloadblog.it/post/3602/una-bibbia-gratuita-per-imparare-ubuntu)
Ubuntu does not use the traditional root account to perform privileged operations, but instead enables users who are members of the admin group to perform all privileged operations by specifying their own passwords.
The rationale for why the root account (and it’s traditional friend, the su root command) are disabled on Ubuntu systems is discussed in the official online Ubuntu documentation at https://help.ubuntu
.com/community/RootSudo. To save you a Web lookup, this is basically viewed as a security improvement, which it certainly can be. Regardless of whether you like this approach, hate it, or are simply puzzled by it, that’s the way that Ubuntu Linux works. Even if you passionately believe that this is an odd approach, you are probably not going to be able to persuade the entire Ubuntu community that it is wrong. Save your breath.
E mettiamoci il cuore in pace :)
N.B. (OT)
La “Bibbia” è incentrata su Dapper, qualche capitolo è banale, ma se sivuole conoscere in dettaglio Ubuntu (specie chi da poco è in questo mondo) la sua lettura è quasi un obbligo …
premetto che utilizzo ubuntu (e gnu/linux in generale) da poco tempo ma credo di saperne abbastanza per comprendere i meccanismi di sicurezza dei sistemi a privilegi multipli ed utenze separate…
detto ciò quello che, però, proprio non riesco a capire (al di là di tutto ciò che dipende dall’utente stesso come, ad esempio, la definizione di una password mediamente sicura) è quale sia la differenza fra un sistema in cui è abilitato il login di root da remoto ed un sistema in cui l’utente root è totalmente disabilitato ma l’utente Pippo può utilizzare sudo….
magari ho detto una castroneria ma, a meno che il problema di sicurezza non sia insito nello script sudo (e con questo intendo la presenza di una qualche vulnerabilità ALL’INTERNO dello script), non riesco proprio a cogliere la differenza
@diavolo_rosso
Sudo non ti fa diventare root e io…
sudo passwd (per come è impostato su ubuntu)
Cmq sudo su un server per come la vedo va assolutamente eliminato come tanta altra roba che viene installata di default.
In fase di hardening del sistema è buona norma giocare con i gruppi, con il poco utilizzato chattr e magari se la distribuzione che si utilizza lo permette con SELinux.
P.S.
credo che tu confonda le figure sistemista ammistratore di rete
Ma pensate veramente che disabilitando l’account root e usando sudo il sistema sia realmente sicuro?
A un hacker esperto poco importa che l’account root sia disabilitato quando sfrutta un bug di un server ad esempio un server ftp.
Qual’è la procedua per aumentare il tempo della sessione sudo (default 5 minuti) ad esempio a 3 ore…in qualche commento precedente mi è sembrato che qualcuno sapesse come fare………..sarebbe utile in qualche occasione.
aridaje anonimo!!
io ho parlato di dare i privilegi di root solo su nano
“sudo passwd” non te lo accetta se non lo specifichi nel sudoers.
Il fatto che ubuntu in fase di installazione conferisca all’utente che installa, una configurazione del tipo “utente ALL=(ALL) ALL” non significa che tutti gli altri utenti aggiunti al sudoers abbiano gli stessi poteri.
@Massimo
nel sudoers aggiungi questa riga
Defaults:tuo_utente timestamp_timeout=tempo_in_minuti
dove tuo_utente va sostituito con l’utente che usi abitualmente e tempo_in_minuti lo dice il nome stesso :) nel tuo caso 180
@firstbit
Hai ragione. Non c’e’ alcuna differenza. Si spostano i problemi dell’uso di root sull’utente pensato come amministratore, sopratutto perchè la password di root e quella dell’utente sono uguali.
L’affermazione ‘sudo è sicuro’ è un evidente errore. E gli ‘utenti più smaliziati’ ….di solito usano root, visto che c’e’ da quando c’e’ unix.
Che posso dire….inquietante sviluppo!
@ pippolino
quindi tu suggerisci di complicare la vita agli utenti alle prime armi per facilitare la vita agli utenti “power”?
non ha molto senso, la prima volta che ho installato ubuntu, su una delle tante guide che ci sono in giro, ho trovato come riimpostare l’utente root, mi sembrava strano che non ci fosse, ho fatto una ricerca e ho trovato come ripristinarlo. poi dopo qualche giorno ho visto che era meglio sudo e ho ritolto il root.
questo solo per dire che se hai voglia di smanettare una soluzione la trovi, ed è giusto che sia lo smanettone a doversi arrangiare, invece secondo te dovrebbe essere l’utente che non sa nemmeno cos’è il root a doversi andare a studiare delle guide, magari in inglese, che gli spieghino come facilitargli la vita.
la vita gliela devi facilitare di default!
@Diavolo Rosso
Provo subito..grazie
per me è uno alle prime armi troverà di sicuro più difficile capire come modificare
il file sudoers che comprendere che loggandosi come root può fare di tutto sul proprio sistema
questo è quello che dice ubuntu
P.S.
il mio giudizio è viziato dalla mia antipatia verso ubuntu
Occhio a disabilitare l’utente root, almeno su server RHEL:
ho fatto lo stesso ragionamento di felipe un po’ di tempo fa, anche a me piace l’idea di sudo ed ho lokkato l’utente root.
Per un problema su un box scsi la macchina e’ andata in crash e al reboot non trovando il filesystem sul suddetto box esterno segnato in fstab la macchina si e’ fermata in single user aspettando la password di… root :-), succede sempre se per es entrate in single user specificando “single” a grub. Unico modo per riprendere il controllo della macchina e’ stato il boot da un live cd per poi riattivare root in passwd!!!
@quelli-alle-prime-armi-non-capiranno:
Per chi è alle prime armi basta usare il comodo users-admin di GNOME, o qualcosa di equivalente per KDE, non siate faziosi, dai :)
@orter:
Ovviamente no, ce ne vuole per dare degli sprovveduti agli sviluppatori di Ubuntu
@l33t-h4x0r-1`M-t3h-m4st3r-0f-uR-l1nUkz:
Forse ad alcuni sfugge un piccolo particolare… Non si trattava di vedere chi immagina la situazione più assurda, faziosa e irreale possibile per poter dire che due password sono meglio di una :D
Se dobbiamo giocare a chi la spara più grossa si arriverà entro poco a teorizzare l’aggressione fisica del sistemista di turno, per farsi dire la parola chiave con cui è stato criptato il filesystem dell’HD rubato dalla cassaforte…
Restiamo un po’ con i piedi per terra, grazie ;)
@Diavolo_Rosso
come ti hanno già fatto notare dare i permessi di root su nano equivale a dare i permessi di root visto che con nano puoi editare i files passwd e shadow
secondo me sudo è una buona scelta per un sistema desktop dove spesso c’è solo un utente e l’amministratore è solo una complicazione non necessaria. per il resto mi sembra che la combinazione gestione gruppi/su sia più indicata a un server, oltre ad essere più elastica
Io non la vedo così tragica in ogni caso… insomma bisgna fare un discorso, come dice Felipe, un po’ più con i piedi per terra.
Ok: la sicurezza è importante. Ma la maggior parte di noi non sta gestendo un server in questo preciso istante indi per cui, visto che le differenze in fatto di sicurezza, fra sistemi “sudati” e non, si vedono in particolare ad alti livelli di interesse dei dati presenti sulla macchina (leggasi: quale cracker ha intenzione di tentare un bruteforce sulla mia password di utenza per leggere i miei documenti? certo se gestissi un server con informazioni riguardo le carte di credito dei miei clienti sarebbe diverso forse..), personalmente non mi preoccupo più di tanto… uso sudo perchè è comodo; certo, non che mi vengano i crampi alle mani se, ogni tanto, faccio il login come root ma finchè tutto ciò non è essenziale mi crogiolo nella mia pigrizia :D
sul dover mettere la pass ogni 5 minuti:
in effetti dava fastidio anche a me, soprattutto quando morivo dalla voglia di incasinare /etc alla follia (o: personalizzare il sistema). senonché, ho avuto questa intuizione quasi epifanica:
$ sudo bash
(o: $ sudo sh, a seconda della shell che preferite).
Restando coi piedi per terra…ma quelle donne in figura sudano o no?
Quasi quasi le invito a casa mia e insegno loro come si fa a sudare per davvero!
Ah, l’anonimo sono io. mi ero dimenticato di mettere il nick
miii felipe che vespaio…
rotfl =D
@davolo_rosso, @massimo
Argh! No non fate cose di quel genere su macchine attaccate a Internet!
Ubuntu pone correttamente nei defaults a TRUE il parametro TTY_TICKETS, voi aggiungete (sempre in default) un bel timestamp_timeout=0.
Se !TTY_TICKETS i token autorizzativi valgono per tutti i terminali una volta sollevati. Il che vuol dire che qualche cattivone potrebbe prendere le autorizzazioni di root da un altro terminale durante una sessione IRC (per esempio) nel periodo della durata dei token.
Il brutto è che se usate un IRC grafico, o qualunque altro client di rete su X-WIndows, questo temo usi :0 e ho il sospetto che potrebbe rendere pericolosa la situazione anche con TTY_TICKETS a true. Le applicazioni grafiche tendo ad usare tutte lo stesso terminale.
Oppure usate sudo -k per invalidare immediatamente i token.
@felipe
Con la massima delicatezza e tutto il rispetto. Proprio per il fatto che tu sei un ‘vincente’ con 18.000 hit al giorno e che naturalmente sei il Beppe Grillo di Linux in Italia, vorrei avessi più cara la sicurezza. Anche perchè ad ogni forum a cui ho partecipato, ad ogni corso, ad ogni riunione (sulla sicurezza) il preambolo è sempre “la sicurezza non è un concetto abbastanza diffuso”.
E’ vero che non ho visto advisory su sudo da un bel pò (da fine 2005), a meno che non mi siano sfuggiti, e che a volte la colpa non era direttamente di sudo, ma è pericoloso l’uso di tutto ciò che aumenta la sicurezza di utenti in un sistema come Linux che, nudo e crudo, non implementa la possibilità di amministrare Access Control Lists. E avere in mente una corretta idea sulla sicurezza è importante per tutti.
Ok smanettare a casa sulla Linux Box mentre con il piede sinistro si smanetta una WII, ma l’alfabetizzazione informatica ha un valore cospicuo.
Ti ritengo più preparato di quello che vuoi dimostrare, e comunque ti prendi la briga di informarti.
E se, dato che siamo un certo numero, ci prendessimo la briga di provare qualche accesso non autorizzato con un UBUNTU a default?
@orter: mai detto che io uso sudo con un timestamp_timeout di 3 ore. e cmq sono dietro firewall altamente selettivo :P
@felipe: non ho capito se l33t-h4×0r-1`M-t3h-m4st3r-0f-uR-l1nUkz sono io, cmq…
Mi pare che tu abbia un concetto di sicurezza abbastanza preoccupante…
La sicurezza o c’è o non c’è… E nel considerare la sicurezza (si discuteva di un server) bisogna essere paranoici e considerare il caso peggiore, così da essere sicuri in tutti i casi che capiteranno…
(Chi avrebbe il coraggio di vendere un antifurto che ferma quasi tutti i ladri, tranne che quelli veramente malintenzionati?)
Non lo dico io, è il concetto standard di sicurezza informatica… Potrei citarti svariati testi. Ma se hai un’opinione (motivata) diversa, ne parliamo (magari per mail che stiamo diventando troppo flammosi e stiamo scrivendo cose che, sinceramente, non credo interessino ai lettori del blog… la mia mail, se tu ne volessi far uso, è nell’URL di questo commento)
Ciao!
P.S: il primo commento al post “Come spaventare tutte le donne della nostra comunità…” è un esempio di come stai facendo diventare questo blog…
Se a te va bene così, nessuno ti può dire niente… Ma a te va bene così?!?
Pingback:Top Posts « WordPress.com
Correzione:
Scusa, mi riferivo al primo commento al post “Mr Ubuntu nella Linux Foundation board”…
@orter:
La sicurezza mi è “cara” così come un mucchio di altre cose, non immagini quante. È fisicamente impossibile chiedermi più di quello che già investo (come tempo, attenzione e passione) su pollycoke, e se su qualche argomento non sono sicuro, semplicemente non lo tratto.
Nell’articolo non ho fatto proclami assoluti, non c’è una sola frase che generalizza e anche dove ho espresso la mia opinione favorevole all’uso di sudo, ho specificato che vale “per certi contesti”, suggerendo implicitamente che per altri possa essere meglio root. Poi chi sa amministrare ed è attento alla sicurezza, lo sa fare a prescindere da questi dettagli.
Non voglio sembrare duro (anzi grazie per aver commentato): non capisco cosa implichi per te essere apostrofati come “beppegrillo di linux”. Lo prendo come un tentativo di complimento ma se permetti cedo volentieri l’onore e passo oltre :)
Buon riassuntone, magari dove dici che sudo è attivo per il primo utente del PC, inserisci che solo gli utenti del gruppo admin hanno il potere di usare sudo come il “primo utente”.
Ah, e magari ricorda che si può aumentare anche il timeout con una semplice righina dell’/etc/sudoers ;)
Bye
Salve a tutti,
anche io mi ritrovo tra i “non entusiasti” di sudo, sarà perché sono abituato al caro vecchio “su toor”*, o magari perché rimango comunque perplesso dall’uso di default che se ne fa su ubuntu.
Ma in questo modo non diventa troppo facile per i malintenzionati poter fare danno sulla macchina di un qualche malcapitato ?
Basterebbe che il malcapitato in questione scaricasse un qualche binario, lo facesse partire, e che poi tra le righe del binario vi fosse qualcosa di banale come:
system (“sudo cat /dev/random > /dev/hda” );
Stando così le cose, non vedo una grossa differenza con l’uso spregiudicato dell’account Administrator che si fa su Windows Xp,
IMHO.
*: su FreeBSD root usa CSH, toor la shell che più si preferisce ( bash )
@sereno:
“e che poi tra le righe del binario vi fosse qualcosa di banale come:
system (”sudo cat /dev/random > /dev/hda” ); ”
a questo punto lo script si pianta e chiede la password dell’utente.
il malintenzionato deve conoscerla questa password, e la può scoprire cosi come può scoprire quella di root. non cambia nulla
@Diavolo_Rosso:
ok, ma su Ubuntu sudo è configurato per non richiedere la password se questa è stata già inserita entro i primi 5 minuti.
E che succede se, – malaugurato caso -, avevamo appena eseguito un qualche comando “sudo”, e poi mandato in esecuzione il famigerato Script / Binario ?
Stasticamente l’evento non è impossibile …
@sereno: Hai ragione, ma se sei a questi livelli di paranoia puoi sempre modificare le impostazioni a tuo piacimento. Nessuno ti vieta di impostare il timestamp_timeout a zero e non fargliela ricordare proprio.
Nel momento in cui devi fare molte operazioni dai sudo -s e ti apri una sessione di root come se avessi dato il comando su.
se parlo con qualsiasi persona di eta e sesso diverso a un certo punto comincio a sudare . Vorrei essere spigato quale e l’origine del caso in questione e cosa bisogna fare per eliminarlo grazie a presto L I N O
sudo xe na merdina. ciò!
@felipe: io aggiugerei solo che se il sistema usa gksu al posto di gksudo bisogna dare sudo gksu-proprierties da terminale dopo la procedura da te descritta, andare ,nella finestra che appare, al menù a tendina affianco a modalità autenticazione e selezionare sudo…Quindi premere ok…E d’ora in poi synaptic in debian lo avvii con la password di sudo ( ovvero lo user )…
errorino…gksu-proprierties va senza il sudo antecedente…
Scusate il doppio post
Ho un problemino…ma come faccio ad usare gli stessi alias definiti per il mio utente normale in .bashrc con sudo?
Ad es. io ho definito un alias così: alias md=’mkdir’ nel file .bashrc
Per l’utente normale nessun problema!ma se faccio sudo md mi dice “comando non trovato”!
Come posso fare ad usare gli stessi alias?grazie
La cosa più sicura su Ubuntu, grazie all’uso di sudo, è che l’account di root è disabilitato. Ho potuto provare i privilegi di persona, quando nel mio auth.log ho trovato un qualcuno che ha provato ad accedere un’infinità di volte con l’account di root, e ovviamente ha sempre fallito. Per poter accedere al mio pc quindi aveva bisogno di due cose fondamentali il mio nome utente E la mia password. In questo senso sudo duplica la sicurezza.
ho discusso proprio l’altro giorno molto animatamente con un amico debian-fanatico che sosteneva che uno dei motivi per cui debian è `più puro` di ubuntu è perché ubuntu non mantiene la separazione tra root e utente normale. L’ho placato dicendogli: `guarda che io sudo anche su debian` e lui: `???` e io: `ho solo dovuto aggiungere il mio utente a /etc/sudoers` e lui `[stupore massimo]…`.
cmq concordo con chi più sopra ha detto che l’installer dovrebbe perlomeno fare un controllo sulla sicurezza della password scelta per l’utente che suderà. su fluxbuntu ho potuto impostare una password di una sola lettera senza che l’installer dicesse nulla. (poi ovviamente l’ho cambiata) però certe cose non dovrebbero essere possibili.
Pingback:make me a sandwich ! « GrayMalkin ^^
In sostanza hai cannato titolo dell’articolo :)
Io l’avrei intitolato “sudo …ma godo!” (come la nota zoccola giapponese)
i love u
Pingback:Integrare KDE 4 in Ubuntu: abilitare sudo at pollycoke :)
Pingback:dugads.com
Pingback:just a tribute :D – notes