Newsgroup: it.comp.os.linux.iniziare
Titolo: sudo è sicuro?

Ho un problema esistenziale, non so se � il caso di fidarmi di sudo. Che 
idee avete in merito visto che voi avete usato molte distro tra cui 
quelle superuser only (su), quelle only sudo e quelle miste?
Io ho usato solo Mandriva e quindi non ho mai usato sudo (eccetto che 
quando usavo il mac diversi anni fa ma si usava poco la linea di 
comando). Con Mandriva o si root o si era utente, quindi le idee erano 
chiare.
Adesso ho installato Pardus, una distribuzione turca che mi piace molto, 
ho fatto tutto con su e in questi giorni ho scoperto che ha pure sudo e 
quindi mi chiedevo che sicurezza del cavolo � quella di potere fare le 
cose che prima facevo con root con solo la password utente.
Forse devo cambiare strategia ed usare password complicate sia per 
l'utente che per l'amministratore. Qui si dice:
Isn't sudo less secure than su?
       The basic security model is the same, and therefore these two 
systems share their primary weaknesses. Any user who uses su or sudo 
must be considered to be a privileged user. If that user's account is 
compromised by an attacker, the attacker can also gain root privileges 
the next time the user does so. The user account is the weak link in 
this chain, and so must be protected with the same care as root.
       On a more esoteric level, sudo provides some features which 
encourage different work habits, which can positively impact the 
security of the system. sudo is commonly used to execute only a single 
command, while su is generally used to open a shell and execute multiple 
commands. The sudo approach reduces the likelihood of a root shell being 
left open indefinitely, and encourages the user to minimize their use of 
root privileges.
Quindi a questo punto potrei usare la stessa password come root e come 
user o comunque evitare password semplici per entrambi. Consigli?
Fonte: 
https://help.ubuntu.com/community/RootSudo
-- 
Sandro kensan 
www.kensan.it
 geek site

 quelle superuser only (su), quelle only sudo e quelle miste?
Ti d� la mia opinione personale senza conoscere se ci sono problemi di 
sicurezza accertati..
Quando devo lavorare in modalit� superutente non sai quanto � fastidioso 
per me dovermi ricordarmi di scrivere sempre "sudo" prima di ogni 
comando.. tre volte su cinque mi tocca andare ad inizio riga perch� 
manca sempre la parolina magica... Molto pi� comodo fare un "su -" e poi 
fare tutte le operazioni all'interno di root e poi uscire.. E' come se 
stai a casa seduto al tavolo della cucina e guardi la tv che sta nel 
salotto.. Tanto vale che ti metti in poltrona direttamente con il 
cartoccio dei popcorn e la birretta sul bracciolo.. :-)

 o comunque evitare password semplici per entrambi. Consigli?
Configurare sudo in modo corretto. La configurazione corretta non è
certamente la classica user ALL = (root) NOPASSWD ma vuol dire configurare
solo i comandi effettivamente necessari per l'esecuzione dei task
amministrativi delegati all'utente.
La sicurezza maggiore la si ha usando per ogni cosa il giusto strumento,
quindi sudo e su vanno usati insieme, ciascuno per la propria parte, e sudo
va configurato correttamente.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 va configurato correttamente.
Ok, questo mi sembra un buon argomento per incominciare a capire. Grazie :)


 cartoccio dei popcorn e la birretta sul bracciolo.. :-)
Cosa � "su -"? Con Pardus ho su e ho sudo. Forse � una cosa di Ubuntu?
Comunque temo anch'io che usare sudo sia scomodo ma vedr� di 
sperimentare la cosa.


 Cosa è "su -"? Con Pardus ho su e ho sudo. Forse è una cosa di Ubuntu?
UBU CHE ????

 UBU CHE ????
LOL :)
Quella che The zipman o ctrix definisce:
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)
-- 



http://en.wikipedia.org/wiki/Su_%28Unix%29
:-)
Ciao, Davide.


 "su -" 
 
legge tutti i files di ambiente che vengono letti dal login 
 


This way users can assume the user environment of the target user.
una opzione di su.



Si, infatti.


 ....
SU nasce per scopi pratici e significa 'switch user' originariamente il 
problema sicurezza non e' il suo scopo principale, tant'e' vero che in un 
sistema normalmente solo gli utenti del gruppo admin possono switchare a 
root, mentre root puo' accedere come qualsiasi utente senza digitare la 
relativa password.
Sudo, che puoi installare su tutte le distro, e' sicuro in base a quanto 
*tu* decidi che lo debba essere configurandolo opportunamente ;-)
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
- Craxi e' solo con se stesso.
- Quell'uomo continua a circondarsi delle persone sbagliate.
		-- ElleKappa

 SU nasce per scopi pratici e significa 'switch user' originariamente il
non "super user"? guarda che se ne imparano di cose...



SuperUserDO ... SUDO
;-)
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
Diventare nonno non e' niente; il brutto e' che ti tocca andare a letto
con la nonna.
		-- Da it.hobby.umorismo

 *tu* decidi che lo debba essere configurandolo opportunamente ;-)
Si ho capito ma le politiche di sicurezza comportano una forte 
conoscenza del sistema per cui io che sono un novizio mi affido alle 
impostazioni di Pardus. In seguito tenterò delle modifiche ma prima è 
meglio che impari tante cose tra cui fare funzionare su e sudo nel modo 
corretto e scelto da chi ha fatto la distro. Per fare questo è bene 
iniziare dall'abc tra cui inquadrare sudo sotto vari aspetti e magari 
cambiare qualche mio pregiudizio, cosa non facile.


 quelle superuser only (su), quelle only sudo e quelle miste?
Anche io condivido questa perplessita'. Secondo me dovrebbe essere cosi' 
la cosa: dare la possibilita' di usare sudo solo a certi utenti 
(tipicamente l'amminastratore), credo si faccia da /etc/sudoers, e 
negarla agli altri utenti, cioe' quelli normali.
Comunque secondo me meglio le distribuzioni dove per certe operazioni 
viene richiesta la pass di root, e non quella dell'utente corrente. E' 
piu' brigoso ma secondo me l'utilizzo di sudo in mano ad utenti 
inesperti lascia praterie dove cracker e malware possono scorrazzare, 
come quel caso (non esattamente attinente) di utenti di un forum mac che 
avevano scaricato ed eseguito un programmino che fra le altre cose 
cancellava tutto il contenuto della home.
Usare sudo invece di su secondo me e' la stessa politica che per anni ha 
seguito la Microsoft incoraggiando gli utenti ad essere admin 
nell'attivita' quotidiana, con tutto il corollario di virus e trojan che 
hanno contribuito alla cattiva fama di windows.

dross ha scritto:

:-)
No, non super user, infatti puoi identificarti con qualsiasi utente
presente:
SU(1)                       User Commands                      SU(1)
NOME
        su - change user ID or become superuser
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 quella di root.
Perch� pensi che le password siano di due categorie?
Le credenziali sono credenziali, e tutte debbono essere commisurate
alla "sensibilit�" del server cui si accede, non al tipo di utente.


 pigs+dogs.
Sì ma solo se usi "sudo" per come è stato pensato, cioè per dare ad 
*alcuni* utenti i privilegi di root *solo* per fare particolari attività.
Che poi alla fine si riduce a permettere l'esecuzione di *script* come 
root, visto che per i binari c'era già il flag su-id... (e si poteva 
anche scrivere un bel wrapper in C da su-idare... prima dell'avvento di 
sudo l'avevo fatto per uno script in tcl-tk che permetteva di usare un 
vecchio scanner Primex parallelo).
Se finisci col fare come nelle varie *buntu, con sudo su aperto a tutti, 
allora è come dare la password di root a tutti, francamente non vedo la 
differenza.
-- 
Massimo Bacilieri AKA Crononauta

 siano script o binari e' un particolare ininfluente.
Sì, questo è chiaro, ma volevo far notare come l'esigenza sia nata per 
gli script, perché per i binari già c'era il flag su-id che alla fine 
faceva lo stesso lavoro di sudo con opzione nopassword.


 differenza.
da sempre considero questo uno degli aspetti negativi di *buntu;
certo si può ribattere che *buntu è indirizzato tipicamente a monoutenti 
e quindi usare sudo o su è praticamente lo stesso, ma così non entrano 
mai nella giusta ottica della netta separazione tra root e users;
senza contare che una volta sgamata la pass dell'user  un cracker, vista 
la diffusione di *buntu, sa che ha anche i poteri di root;
r
-- 
Hare hare supermarket !
Hare hare supermarket !
[Daevid Allen: Other Side of the Sky]
Ramapage: 
http://umpf.net/

 hanno contribuito alla cattiva fama di windows.
L'esatto opposto. Sudo serve proprio per evitare che gli utenti eseguano per
praticità tutte le operazioni come root.
-- 
Flavio Visentin


 cambiare qualche mio pregiudizio, cosa non facile.
L'unico modo corretto e' usare la testa e rapportarsi correttamente 
all'uso che viene fatto del sistema. In un sistema *davvero* multiutente 
e' piu' sensato usare sudo e comunque di fondo anche in un sistema 
monoutente o quasi e' concettualmente sbagliato l'uso (direi piu' abuso)  
di su e quindi relativa password di root. Per concludere...direi... 
meglio sudo opportunamente configurato SEMPRE.
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
By protracting life, we do not deduct one jot from the duration of death.
		-- Titus Lucretius Carus


Facebook: Massimo Bacilieri

 bisogno di un login specifico per farlo.
Eh si certo...se non che per farlo devi conoscere la password di root e 
avere pieno accesso al sistema...alla faccia della sicurezza.
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
Tartaruga trafelata: "Ho dovuto attraversare un ponte dove c'era scritto
``a passo d'uomo''...".
		-- Da it.hobby.umorismo

 avere pieno accesso al sistema...alla faccia della sicurezza.
E una volta che hai fatto "sudo su" cosa cambia?


 E una volta che hai fatto "sudo su" cosa cambia?
Che normalmente l'utente non puo' nemmeno eseguire su da superutente 
Capito adesso?
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
- Perche' i carabinieri mettono la sveglia per terra?
- Per vedere se cammina.
		-- Da it.hobby.umorismo

 sistema.
E quando fai sudo su cosa diventi mai? Il discorso è questo.
Se dai la possibilità agli utenti di fare "sudo su" con la *loro* password,
abbiamo già potenzialmente una voragine di sicurezza. Il resto è filosofia.


 filosofia.
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
# Uncomment to allow members of group sudo to not need a password
# %sudo ALL=NOPASSWD: ALL
# Host alias specification
# User alias specification
# Cmnd alias specification
Cmnd_Alias     SU = /bin/su
# User privilege specification
root	ALL=(ALL) ALL
crunch  ALL = ALL, !SU
# Members of the admin group may gain root privileges
# %admin ALL=(ALL) 
questa non e' filosofia
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
It's not so hard to lift yourself by your bootstraps once you're off the 
ground.
		-- Daniel B. Luten
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
It's not so hard to lift yourself by your bootstraps once you're off the 
ground.
		-- Daniel B. Luten

 questa non e' filosofia
No, ma non cambia una fava: a parte inibire il passaggio a root, in 
questo modo permetti comunque all'utente crunch di eseguire qualsiasi 
cosa coi privilegi di root, escluso unicamente "su". Il che, se mi 
permetti, sposta poco il problema, visto che con la password utente 
posso eseguire comandi come sudo rm -rf / oppure un bel sudo cp viral_ls 
/bin/ls, dove "viral_ls" è un bel worm, con tanti saluti.
Senza contare sudo visudo... :-) Ci hai pensato?
Ah, inoltre con la sintassi che hai usato, al tuo utente è inibito 
lanciare *esattamente* /bin/su, ma siccome a parte quello può fare 
qualsiasi cosa, un bel sudo cp /bin/su /usr/local/bin/su e poi sudo 
/usr/local/bin/su non so se te lo blocca... (non ho provato, è un 
esperimento interessante).
AKA, se un malware riesce mentre navighi a prendere la tua password 
utente (che magari è la stessa che usi per loggarti su qualche forum, 
magari non tu nello specifico ma tanti utenti lo fanno: mai 
sottovalutare l'idiozia degli utenti), tramite dei bachi di sicurezza 
del browser o altri applicativi può potenzialmente arrivare riscriverti 
*qualsiasi* eseguibile a livello sistema.
Cioè in men che non si dica siamo arrivati a un sistema vulnerabile 
stile Windows... un bel guadagno neh? Dopodiché cosa facciamo? Mettiamo 
un bell'antivirus che cerchi di intercettare le attività dell'utente 
quando prova a fare qualcosa di dannoso?!
Rischi che non esistono se per eseguire qualcosa coi permessi 
amministrativi sei forzato ad aprirti una shell e passare a root in modo 
esplicito.
sudo va bene solo per concedere in modo *molto* restrittivo la 
possibilità di eseguire *alcune* e ben selezionate applicazioni coi 
permessi di superuser, superando i limiti del flag su-id.
Diventa un boomerang quando lo si usa per concedere "tutto tranne...".
Io per esempio ho dato la possibilità al mio utente di eseguire come 
comandi le sequenze di fetchnews e apt-get update ; apt-get upgrade, in 
questo modo da user posso lanciare lo scaricamento delle news (evitando 
di su-idare fetchnews) ed attivare l'aggiornamento di sistema senza 
commutare ogni volta a root.
Un eventuale malware che attacchi il mio utente può al massimo... farmi 
scaricare le news o aggiornare il sistema :-)
Ho permesso poche altre attività di questo tipo. L'utente non deve poter 
fare *qualsiasi* cosa con permessi di super user semplicemente 
premettendo "sudo" al comando, altrimenti è ben poco dissimile dal 
girare come root.


 crunch  ALL = ALL, !SU
Ah, quindi sudo visudo...
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Se dai la possibilità agli utenti di fare "sudo su" con la *loro* password,
E non dargliela, la possibilità.
Il discorso è tutto nelle poche paroline uscite nella parte iniziale del
thread: l'utente con sudo esegue solo ciò che root ha deciso di fargli
eseguire perché gli è indispensabile. Stop.


cosa coi privilegi di root, escluso unicamente "su".
Scusa se ne approfitto, io non uso sudo e lo purgherei (ho
la squeeze) se non fosse che ha decine di reverse dipendenze
che me lo impediscono.
Questo e' il mio sudoers e io non c'ho mai messo le mani:
=================================
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root	ALL=(ALL) ALL
# Allow members of group sudo to execute any command
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=(ALL) ALL
#
#includedir /etc/sudoers.d
========================================
Puoi dirmi cosa fare per neutralizzarlo completamente? sai
man sudo visudo sudoers sono centinaia o migliaia di righe
e poi non sarei mai sicuro d'interpretarle bene, grazie in
anticipo se potrai dirmi qualcosa.
Ps. In particolare, leggendo questo thread, mi spaventano
quelle tre uniche righe non commentate e che non capisco,
mi viene una voglia tremenda di commentarle a mano.. ma dice
d'usare visudo e un motivo ci sara' se c'e' MUST maiuscolo!
-- 
Saluti, Dalet

 girare come root.
Il tuo punto di vista mi sembra più comprensibile ma non sono in grado 
di affrontare una discussione tecnica in materia.


 d'usare visudo e un motivo ci sara' se c'e' MUST maiuscolo!
Usa visudo, penso abbia gli stessi comandi di vi.


 Usa visudo, penso abbia gli stessi comandi di vi.
Non � sempre cos�, difatti in Debian squeeze visudo lancia nano come editor.
Visudo esegue alcune verifiche prima di uscire (a differenza di uno 
editor "stupido"), man visudo:
visudo edits the sudoers file in a safe fashion, analogous to vipw(8). 
visudo locks the sudoers file against multiple simultaneous edits, 
provides basic sanity checks, and checks for parse errors.  If the 
sudoers file is currently being edited you will receive a message to try 
again later.


In sostanza la questione e' che se sbagli ad editare /etc/sudoers, poi 
non potrai piu' usare sudo, e nemmeno correggere sudoers perche' bisogna 
usare sudo per poterlo fare! Per questo visudo fa cio' che descrivi, e 
cioe' esegue un controllo di coerenza prima di salvare.

 d'usare visudo e un motivo ci sara' se c'e' MUST maiuscolo!
  Si, infatti.  Dalla pagina man visudo(8):
DESCRIPTION
	visudo edits the sudoers file in a safe fashion, analogous to
	vipw(8).  visudo locks the sudoers file against multiple
	simultaneous edits, provides basic sanity
	checks, and checks for parse errors.  If the sudoers file is
	currently being edited you will receive a message to try
	again later.
  Ciao,
-- 
Alessandro Selli, 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B


appunto, ero convinto che fosse una cosa tipo "ora sono super user, 
dammi il diesis prima dei comandi che faccio 1 mucchio di belle cose"

 editor.
  Come spiega la pagina man visudo(8), visudo usa l'editor specificato in
fase di configurazione (prima della compilazione), oppure quello specificato
nel file di configurazione sudoers, che di default è "/bin/vi". In
alternativa, se una della variabili d'ambiente VISUAL o EDITOR contiene uno
degli editor elencati in precedenza, allora visudo sceglie quello che vi è
indicato.


 cioe' esegue un controllo di coerenza prima di salvare.
Allora per i sistemi monoutenti come molti lo sono qua dentro e 
conveniente fare un bel # nano /etc/sodoers e se ci sono problemi si 
ricambia il file: giusto?
P.S. io uso nano come editor.


che gli pare.
Thx!! quindi e' gia' del tutto - per default di Debian - come
se sudo non fosse installato.
-- 
Saluti, Dalet

 se sudo non fosse installato.
a me sembra il contrario, visto che la riga non è commentata è attiva, no?
r
-- 
Sulla tosticita' della Slackware ovvero Quale distro?
distribuzioni sedicenti amichevoli e realmente tali:
http://www.umpf.net/ramapage/

a me sembra il contrario, visto che la riga non è commentata è attiva, no?
Io ho pensato questo: chi e' in grado di aggiungere un
utente al gruppo sudo, e' inutile che lo faccia perche'
piu' semplicemente puo' aggiungerlo direttamente al
gruppo root.. in cosa sbaglio?
In ogni caso, e visto che tanto a me sudo non serve proprio
a nulla, posso editare sudoers con visudo e commentarlo,
sempre che non ci siano controindicazioni.. cosa mi consigli?
-- 
Saluti, Dalet

 cosa coi privilegi di root, escluso unicamente "su". Il che, se mi
Ehm...si, questo lo sapevo anch'io era solo per mostrarti come si possa 
rapidamente configurare sudo, in particolare mi pare ci si fosse 
incancreniti su 'sudo su'....
Ovvio che puoi limitare il tuo utente come vuoi, dato che sudo e' uno 
strumento appositamente pensato per la gestione della sicurezza mentre su 
come gia' detto assolutamente no.
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
It's currently a problem of access to gigabits through punybaud.
		-- J. C. R. Licklider

 sempre che non ci siano controindicazioni.. cosa mi consigli?
penso di sì, ma non sono un esperto in sicurezza;
eppoi non mi pongo eccessivi problemi, non è che abbia un server da 
amministrare -e sudo io non l'installo mai ;-P


 Mi potresti fare vedere il tuo sudoers?
Eccolo:
---8<---
# User alias specification
User_Alias	MANAGER = ulibarra
User_Alias	AUDIOERS = %audio
User_Alias	PONNERS = %dip
# Cmnd alias specification
Cmnd_Alias	MANAGING = /usr/bin/apt-get
Cmnd_Alias	QJACKCTL = /usr/bin/qjackctl
Cmnd_Alias	JACKD = /usr/bin/jackd
Cmnd_Alias	AEOLUS = /usr/bin/aeolus
Cmnd_Alias	MUSE = /usr/bin/muse
Cmnd_Alias	LADCCAD = /usr/bin/ladccad
Cmnd_Alias	QARECORD = /usr/local/bin/qarecord
Cmnd_Alias	JACKCONN = /usr/bin/jack_connect
Cmnd_Alias	ACONNECT = /usr/bin/aconnect
Cmnd_Alias	PON = /usr/bin/pon
Cmnd_Alias	POFF = /usr/bin/poff
# Host alias specification
# User privilege specification
root	ALL=(ALL) ALL
MANAGER ALL = NOPASSWD: MANAGING
AUDIOERS ALL = NOPASSWD:QJACKCTL,JACKD,AEOLUS,MUSE,LADCCAD,QARECORD,JACKCONN,ACONNECT 
PONNERS ALL = NOPASSWD: PON,POFF
--->8---
Come vedi, tutto quello che possono fare gli utenti è limitato a apt-get
per l'utente "ulibarra" (il mio utente), quei programmi audio per quelli
iscritti al gruppo audio (per una storia del realtime in jackd che con
certi kernel funziona solo da root), e del gruppo "dip" che può eseguire
"pon" e "poff" che sono degli script di Debian per gestire le connessioni
dialup: usualmente queste non avrebbero bisogno di sudo, visto che pppd è
su-id, ma io li uso per un tunnel vpn con pptp che per motivi che non ho
mai approfondito non mi funziona col semplice flag su-id: ecco la vera
utilità di sudo.
Posso così avviare pon e poff che sono *script* coi privilegi di root, cosa
impossibile col flag su-id. A quel punto, pptp viene invocato come
superuser e mi funziona regolarmente.
Naturalmente, per avviare pon e poff occorre che l'utente sia iscritto al
gruppo di sistema "dip", così come per lanciare i vari jackd et sim via
sudo occorre essere iscritti al gruppo audio.
Questo è tutto quello che il mio sistema permette di fare con sudo, quindi
vedi che se anche uno mi "crackasse" in qualche modo l'utente, via sudo
farebbe ben poca strada.
La riga root ALL=(ALL) ALL è retorica, visto che root non ha certo bisogno
di sudo per avviare programmi con privilegi di root :-)
(e non ho infatti mai capito come mai sia inserita di default :-O ).
-- 
Massimo Bacilieri AKA Crononauta 



-- 


 programma dai repository, 
Uhm... ora che mi ci fai pensare... piuttosto... potrebbe farmi apt-get
REMOVE a casaccio... moh sai che quasi quasi lo poto via? ;-)


 REMOVE a casaccio... moh sai che quasi quasi lo poto via? ;-)
Eccolo corretto!
User_Alias	MANAGER = ulibarra
Cmnd_Alias	UPDATE = /usr/bin/apt-get update
Cmnd_Alias	UPGRADE = /usr/bin/apt-get -y upgrade
Cmnd_Alias	DISTUP = /usr/bin/apt-get dist-upgrade
MANAGER	ALL = NOPASSWD: UPDATE,UPGRADE,DISTUP
Così ora può *esplicitamente* solo fare:
apt-get update ; apt-get -y upgrade ; apt-get dist-upgrade
che ho poi per comodità riunificato sotto un alias utente:
UPDSYS='sudo apt-get update; sudo apt-get -y upgrade; sudo apt-get
dist-upgrade'
Ora non può installarmi o disinstallarmi niente, può *solo* fare ciò che è
pensato per fare.
Una volta di più questo dimostra che le insidie sono dietro ogni angolo...
e che ogni discussione è costruttiva!



Anche windows, se configurato bene, e' molto sicuro. Io lo suo come 
utente non amministratore e faccio tranquillamente a meno 
dell'antivirus. Quando devo fare qualche operazione particolare uso 
"esegui come..." che mi chiede la pass di administrator, come per 
esempio Mandriva che mi chiede la pass di root per operazioni simili.
Il problema qui' e' che con ubuntu (il linux di gran lunga piu' diffuso) 
il default e' che con sudo esegui qualunque operazione. Siccome il 99% 
degli utenti non esegue configurazioni a quel livello, ne discende che 
avere abilitato sudo fa decadere enormemente la sicureza del sistema.
E' l'eterno dilemma fra semplicita' e sicurezza. La diffusione richiede 
la semplicita', e lo hanno capito bene alla apple, microsoft e 
canonical, ma con i buchi di sicurezza conseguenti.

 avere abilitato sudo fa decadere enormemente la sicureza del sistema.
Se molta gente esperta parla male di Ubuntu vuol dire che ci sono molte 
gravi mancanze in Ubuntu. Questa è una.

 gravi mancanze in Ubuntu. Questa è una.
E' semplicemente che ubuntu e' studiata per uso dektop casalingo, 
nessuno si sognerebbe di usarlo in ambiente "corporate", ma del resto 
chi usa linux in ambiente "corporate", parlando di workstation?

 dell'antivirus.
Teoricamente è ineccepibile, all'atto pratico siccome gli applicativi 
per Windows li scrivono gente che andrebbe decorticata e girata nel sale 
anziché messa a fare programmi (*), da semplice user ti funzionano 
giusto Office e il notepad.
Non ti racconto neanche la quantità di gestionali, scritti con piedi e 
culo, che per funzionare *esigono* che l'utente sia administrator, 
giusto per fare un esempio a livello aziendale.
Hai voglia a parlare di sicurezza, dopo... :-/
(*) e la grave, gravissima colpa di M$ è quella di offrire una 
piattaforma che si presta a questa oscenità informatica. Tantovaleva 
continuare a fare Windows 98, ci guadagnavano tutti in semplicità, ché 
la sicurezza poi è la stessa.


 giusto per fare un esempio a livello aziendale.
Non so, la mia esperienza e' diversa, i programmi che richiedono 
privilegi di admin sono stati pochissimi finora, e di solito ho risolto 
dando i pieni diritti allo user ma solo sulla cartella del programma, 
non dando allo user i privilegi di admin su tutto windows.

 chi usa linux in ambiente "corporate", parlando di workstation?
Fatti un giro su it.comp.os.linux.sys e poi vedi quanti parlano
di Ubuntu, Ubuntu server e simili amenità. Fai una bella ricerca 
con Google groups poi ne discutiamo.
PS Sono dieci anni che non sento parlare di workstation ;-)

 la sicurezza poi è la stessa.
Microsoft ha delle guideline, sta alle software house rispettarle.

 giusto Office e il notepad.
Il problema è che la sicurezza dipende dai comportamenti dell''utente.
La pecca di Windows NT / Vista / seven è che hanno tutti gli strumenti
necessari per essere sicuri che gli utenti possono tranquillamente 
ignorare perché il sistema operativo, i programmatori e la Microsoft
non fanno niente per obbligare gli utenti a rispettare le norme minime 
di sicurezza, tranne che fare raccomandazioni e linee guida che nessuno 
segue. 

 segue.
Ma che differenza pratica c'e' fra sudo come concepito da Ubuntu e OSX e 
invece l'UAC di Vista e Seven?

 root (dato che entrambe sono gestite dalla *stessa* persona).
Beh è vero fino ad un certo punto. Per passare a root *devi* 
necessariamente, ogni volta e senza eccezione, farlo esplicitamente in 
una shell.
sudo invece ha una sua cache, metti la password una volta e dopo se 
richiami sudo entro 5 minuti (valore di timestamp_timeout di default) 
non te la chiede una seconda volta.
Il che vuol dire che se hai fatto un lavoro con sudo e subito dopo col 
browser navighi su un sito con script o applet "virali" che sfruttano 
debolezze del browser stesso, teoricamente a quel punto stai a tutti gli 
effetti navigando con potenzialità di root. Che è *male*.
Questo può succedere con il "su" tradizionale, che si apre e si 
esaurisce nella shell che usi.
Ammetto che è uno scenario con molti "se" e "ma", tuttavia per la legge 
dei grandi numeri, e data l'enorme quantità di gente che naviga al 
mondo, qualche caso può statisticamente capitare. E non vorrei essere 
io! ;-)


Addì  mercoledì 17 novembre 2010 11:57 Ale scrisse:

Io non sono esperto di OSX e Windows Vista/Seven non mi passano manco 
per la testa per cui preferisco non rispondere alla domanda.
Però noto che qui si sta discutendo di come rendere sudo e su più sicuri 
(perché il punto della discussione è che bisogna configurare sudo con 
accortezza perché anche sudo ha i sui lati negativi) ma nessuno si sogna 
di scavalcare l'account root perché rompe le palle. Invece...
http://www.google.it/search?q=uac+windows
 
| #
| Disabilitare UAC in Windows Vista
| 4 giu 2007 ... Il sistema che controlla gli account degli utenti, meglio
| noto come UAC è una delle funzionalità di Windows Vista, pensate per
| proteggere ...
| 
www.downloadblog.it/.../disabilitare-uac-in-windows-vista
 - Copia cache - 
| Simili
| #
| Disabilitare UAC in Windows 7 e Vista - GiardiniBlog
| Per rendere Windows sicuro, Microsoft ha deciso di dotarlo di un modulo di 
| protezione che prende il nome di UAC, ( Controllo Account Utente), ...
| 
www.giardiniblog.com/disabilitare-uac-windows-7-vista/
 - Copia cache - 
| Simili
| #
| Disable UAC in Windows Vista - Petri - [ Traduci questa pagina ]
| 8 Jan 2009 ... Windows Vista has the built-in ability to automatically 
| reduce the potential of security breaches in the system.
| 
www.petri.co.il/disable_uac_in_windows_vista.htm
 - Copia cache - Simili
| ...

 
http://www.google.it/search?q=uac+windows
ci sono pero' casi in cui "serve" non averlo. Mio suocero (quasi ottantenne) 
ha un pc con vista _non_ connesso ad internet, che usa esclusivamente per 
giocare e l'UAC non gli serve proprio. I giochi glieli fornisco io, 
regolarmente acqustati e glieli installo, quindi nessun rischio virus.
-- 
Ciao!
Se hai voglia e tempo visita il mio sitarello!
www.moredifficult.org
www.liftman.org
http://florezia.myminicity.com
 

 regolarmente acqustati e glieli installo, quindi nessun rischio virus.
Tempo fa dei giochi o dei software regolarmente acquistati venivano 
venduti con virus che si era intrufolato in qualche anello della catena. 
Poi se hai un sistema non aggiornato è peggio.
Come al solito meglio linux.



Ma non sarebbe meglio usare un utente limitato invece che un 
administrator con il cane da guardia dell'UAC?

 non te la chiede una seconda volta.
Di default anche sudo muore nella shell da dove è lanciato:
tty_tickets     If set, users must authenticate on a per-tty basis.
                 Normally, sudo uses a directory in the ticket dir with
                the same name as the user running it.  With this flag
                enabled, sudo will use a file named for the tty the user
		is logged in on in that directory.  This flag is
		@tty_tickets@ by default.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_____________________________________________________________________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/
 
http://www.worldcommunitygrid.org/index.jsp
 
http://boinc.berkeley.edu/projects.php

 Se finisci col fare come nelle varie *buntu, con sudo su aperto a tutti,
Ma di che diavolo andiamo parlando?
sudo è aperto all'utente installatore, che sui su sistemi desktop, di
norma, è fisicamente anche il sysadmin. Non è affatto aperto agli
altri.
lem@biggy:~$ sudo adduser prova
Aggiunta dell'utente «prova» ...
[...]
lem@biggy:~$ su prova
Password: 
prova@biggy:/home/lem$ sudo cat /etc/sudoers
[sudo] password for prova: 
prova is not in the sudoers file.  This incident will be reported.
prova@biggy:/home/lem$
Quindi?


 rischio virus.
Prima di tutto "Non connesso ad INTERNET" non vuol dire "nessun 
problema di sicurezza". La sicurezza è anche proteggere il computer
dagli utenti legittimi, visto che la maggior parte egli attacchi ad un 
sistema multiutente viene da utenti legittimi. Va, bene hai fatto un 
esempio particolare, ma anche in un sistema monoutente l'attacco alla 
sicurezza viene dall'utente stesso. Cioè voglio dire, un utonto che avvia 
il computer con l'account di amministratore per giocare a solitario è un
attacco alla sicurezza; non installerà rootkit, non si infetterà con virus e
worm. ma può cancellare la directory /etc o /usr/bin.
Poi nello specifico, un sistema operativo serio se individua una violazione
dei permessi manderà un messaggio del genere: "Operazione non consentita."
o "Non hai il permesso di fare questo!" o "Che cavolo stai facendo Willis?"
Invece Windows cosa fa? Ti mostra una finestra che chiede di immettere una
password. Ok, ma la colpa non sarà dell'utonto che certamente immetterà
quella password.
 

 effetti navigando con potenzialità di root. Che è *male*.
Ovviamente i manuali non si leggono, tantomeno il manuale di sudo,
nè si conosce l'opzione -k
Il problema non sta in su o sudo ma nell'utonto che quando finisce
l'operazione non digita "sudo -k" od esce dalla shell di root.

 Quindi?
Quindi siccome l'utente installatore è anche quello che userà il pc come
utente...
-- 
Massimo Bacilieri AKA Crononauta 


 typed:

in realta' l'amministratore nelle versioni home (sia di xp, che vista e 
seven) e' disabilitato per default, ma l'utente normale ha ugualmente 
privilegi (quasi) amministrativi (il quasi e' l'UAD...)



Stiamo aggirando il problema.
È perfettamente chiaro che se uno *sa* configurare sudo, e soprattutto 
se *sa che lo deve configurare* (che è già una cosa diversa ancora) il 
problema non esiste.
Sudo è uno strumento potente, flessibile ed utile, che però proprio in 
quanto flessibile può essere deformato fino a diventare una porcheria.
E questo è quanto viene fatto in ambienti che permettono il sudo su come 
modo di default di passare a superuser (root).


 sarà dell'utonto che certamente immetterà quella password.
anche certi SO meno seri (qualsisai riferimento ai SO MS e' puramente 
casuale...), impediscono le cazzate estreme, permessi o non permessi. Per 
capirsi, _non_ puoi formattare il disco di sistema, _non_  puoi eliminare la 
directory "windows" e i relativi files protetti dal sistema (ovviamente a 
patto che non si disabiliti, oltre all' UAC, ove presente, pure la 
protezione dei files di sistema. Oltretutto modi di far danni ne esistono a 
bizzeffe, uno dei piu' diffusi e' pure quello di staccare la spina al volo 
perche' il computer si e' bloccato...
Resta il fatto che (IMHO) un computer non connesso in rete, di un singolo 
utente che si limita a giocare a qualche gioco che ha a portata di mano sul 
desktop, password di root o privilegi amministrativi che siano, per me resta 
sicuro al 100% (perche' nel caso specifico se il computer non va', ci si 
limita ad una telefonata) dato che, se si rovina qualcosa del sistema non e' 
certo per colpa dell'utilizzatore. In piu' nei sistemi MS c'e' il ripristino 
della configurazione che spesso e volentieri e' risolutivo.


 Come al solito meglio linux.
Se mai ci sara' una diffusione maggiore rispetto ad adesso, cresceranno sia 
i malware che gli utenti che faranno d itutto per beccarseli (e cercare di 
impestare pure gli altri...)


 utente...
Ok, la tua posizione è chiara. Ci ho visto due critiche, non a sudo in sé 
(che potrebbe esser configurato per diventare senza dubbio ben più 
conservativo - e sicuro - di su) bensì:
a) all'opportunità di fornire sudo come strumento di default per compiere 
azioni d'amministratore;
b) al modo in cui sudo è configurato di default.
Entrambe le critiche sono contestualizzate: il sistema di riferimento ad è 
utonto@desktop.
PUNTO a).
Riguardo ad a) si sostiene che sudo confonda l'utonto: meglio sarebbe 
abituarlo a tenere esplicitamente ben distinte le identità con cui opera: 
o è utente, o è root, o è $sarcazzo: niente miscuglio vario di maschere e 
costumi.
Estremizzando, però, tale critica metodologica potrebbe benissimo essere 
rivolta anche a su, specie quando questo sia usato in ambiente dektop dal 
basso verso l'alto, cioè per diventare root: che bisogno c'è di su? Che 
bisogno c'è di cambiare identità, quando si può fare un altro login?
L'unico bisogno è quello di comodità, ma questa comodità si può pagarla in 
sicurezza: con su dimenticarsi della propria identità del momento è più 
facile che non se si fosse costretti, quando s'avesse bisogno di root, a 
loggarsi in una bella tty (non pts) tuutta nera, tuutta a caratteri, tuutta 
fuori da X... tuutta una gran rottura di palle.
Abbandonando la critica concettuale, e entrando in campo pratico, 
confrontiamo le due alternative (sempre avendo in mente il nostro sistema 
di riferimento: utonto@desktop): su una Ubuntu, per esempio, root 
esplicitamente non funziona (AKA: qual è la password di root?). Non ci si 
può direttamente loggare come root (mai, quindi neppure via X!), non si 
conosce né si può usare "su" per diventare root, ergo ben pochi conoscono 
un papocchio quale  "sudo su": non possiamo tacerlo, se vogliamo rimanere 
nella realtà. Certo, c'è "sudo -i"... Ci sono altre possibilità. Ma, anche 
qui, siamo un po' dove osano le aquile: chi legge i man? No, AFAIK ben 
pochi utenti di Ubuntu ricorrono a scorciatoie di quel tipo: invece, si 
sorbiscono il sudo ogni volta che ne hanno bisogno.
Prima di passare all'analisi della configurazione di default di sudo, 
chiediamoci in linea generale: è meglio un sistema (sudo) che, quando mi 
fa diventare root, implica normalmente anche il successivo abbandono 
automatico di tale identità, oppure uno (su) che normalmente non lo 
implica? La domanda è retorica. ;)
Il che ci porta al
PUNTO b).
Configurazione di default di sudo su Ubuntu. Solo gli aspetti degni di 
nota.
sudo chiede la password dell'utente. Per forza: è l'unica password che 
l'utente installatore di Ubuntu conosce, è l'unica che è possibile 
chiedergli. Quindi? È il fatto di dover inserire una password, la sua 
password, la sua unica password, cosa che in genere _NON_ deve fare, che 
lo avverte che sta entrando in un area di pericolo.
Salvo accorgimenti, i benefici di root permangono per qualche minuto (ma 
solo nella tty o nella pts in cui è stato lanciato) dall'ultimo utilizzo. 
Comodo. Ed è meglio di su. ;)
Tuttavia in console con su posso vedere facilmente chi sono (il che non 
implica che me ne accorga per forza), mentre dopo aver usato sudo posso 
dimenticarmi di avere ancora i diritti di root. Questo è un fatto, ma non 
mi pare granché preoccupante: tanto "sudo" lo devo ridigitare comunque, e 
se lo ridigito voglio ridiventare root. 
Va beh, l'unico "problema" di travalicamento di confini che vedo è il 
ticket unknown, che è un jolly che vale per le applicazioni grafiche (ma 
non tutte le applicazioni grafiche usano gksudo, alcune forzano gksu).
Quanto alla eventualità da te suggerita in altro messaggio, cioè la 
possibilità che navigando, dopo aver usato sudo per un'applicazione 
grafica, s'incorra in problemi di sicurezza dovuti all'esecuzione di 
malware con diritti di root, io francamente non sono all'altezza di 
disquisire con piena cognizione di causa. Il tema del safe browsing è poi 
già complesso di per sé. Per ora mi chiedo solo: ma qualche esempio di 
problemi vissuti? "Grazie a sudo mi hanno sfasciato il sistema": mai 
sentito. E sì che Ubuntu è senza dubbio la distribuzione linux più 
diffusa, e da un bel po'.


 impestare pure gli altri...)
Non so, di distro ce ne sono talmente tante che non è facile per un 
virus intrufolarsi se non sa nemmeno il path del file che è buggato. Io 
poi scelgo distro non troppo diffuse, penso che così ci siano meno 
problemi dei già pochi problemi che ha linux.


 modo di default di passare a superuser (root).
Come faceva giustamente notare qualcuno ubuntu di default ha l'utente 
root disabilitato di default quindi tutto sto discorso su 'sudo su' viene 
inesorabilmente a cadere. Ipotizzando invece di abilitarlo, con sudo si 
puo' mettere a disposizione dell'utente solo quegli eseguibili che si 
vuole e negare l'accesso alle dir di sistema.
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
QOTD:
	"It's been real and it's been fun, but it hasn't been real fun."

 ...
No, solo che il problema della sicurezza è una questione di comportamenti, 
sia che si tratti di un utonto che non sa configurare sudo o di un bambino 
che non sa usare un coltello o di un muratore che sale su una impalcatura 
senza nè casco nè cintura di sicurezza.
Il problema è sempre seduto davanti alla tastiera anche quando l'utonto
prepara una distribuzione.

 giusto modo di fare le cose (ovvero l'elevazione di privilegi).
Merda, policykit mi ha fatto già venire il sangue acido in un paio di
occasioni... credo di averlo disabilitato <g>


Il 26-11-2010, Crononauta dice:



Come hai fatto a disabilitarlo? io i *pol* li ho tolti
tutti (c'ho solo kde e niente gnome tranne i giochi),
ma questi dselect non me l'ha permesso di purgarli:
libpolkit-agent-1-0			install
libpolkit-backend-1-0			install
libpolkit-gobject-1-0			install
libpolkit-qt-1-0			install
libsepol1				install
policykit-1				install
polkit-kde-1				install
-- 
Saluti, Dalet

 polkit-kde-1				install
Uhm... io ho solo il backend, il gobject e il policykit-1.
Non mi ricordo onestamente cosa avevo combinato, so che una volta dopo un
update ha cominciato a sfrappolarmi gli zebedei e devo essere andato giù
pesante di apt-get remove --force... ;-)
Credo che fosse per permettere lo shutdown del sistema da XFCE4, ero andato
dietro a /etc/dbus-1/system.d/hal.conf, però se mi chiedi cosa avevo fatto
non te lo so dire.
Sinceramente non ho mai approfondito il policykit.
-- 
Massimo Bacilieri AKA Crononauta 
