Fangala! Fedora12 rende di default gli utonti dei simil-superutenti
Alessandro Selli
utenti non privilegiati di installare qualsiasi pacchetto firmato nei
repository senza dover inserire la password di root:
Il motivo per questo comportamento ancora non documentato
(https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00926.html)?
Che la Fedora12 ￜ pensata per l'uso desktop monoutente, non per l'uso
server e/o multiutente.
Sysadmin avvisati (ma neanche troppo), sysadmin mezzi salvati.
(Brontolio rancoroso sul dilagare dell'effetto Ubuntu... GGRrrrr!)
--
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
Vide
> (Brontolio rancoroso sul dilagare dell'effetto Ubuntu... GGRrrrr!)
Veramente su ste cose genralmente è Fedora che incasina di più la vita ad
ogni release, dato che è *sempre* bleeding edge (ma dato che è meno
popolare, se ne parla meno).
--
Vide
Andrea B. @wrk
> Che la Fedora12 ￜ pensata per l'uso desktop monoutente, non per l'uso
> server e/o multiutente.
>
> Sysadmin avvisati (ma neanche troppo), sysadmin mezzi salvati.
>
> (Brontolio rancoroso sul dilagare dell'effetto Ubuntu... GGRrrrr!)
>
>
Bellino! Almeno ubuntu consente solo agli utenti del gruppo admin di
usare sudo.
Santo Capolozo
> Bellino! Almeno ubuntu consente solo agli utenti del gruppo admin di
> usare sudo.
Giￜ, e per un quarto d'ora senza reimmettere la password.
Questa cosa non l'ho mai capita: basta attendere che prima o poi
l'utente legittimo utilizzi sudo e chiamarlo in un'altra stanza.
A questo punto basta da utente non privilegiato un "sudo su" seguito da
"passwd" per abilitare root a proprio piacimento e per usi futuri...
Perchￜ quelli di Ubuntu non impostano di default timestamp_timeout=0 ?
E se inserire spesso la password ￜ una seccatura tanto vale abilitare root.
O no?
Alessandro Selli
> On 2009-11-19, Santo Capolozo<nessuni...@nessunindirizzo.net> wrote:
>> Questa cosa non l'ho mai capita: basta attendere che prima o poi
>> l'utente legittimo utilizzi sudo e chiamarlo in un'altra stanza.
>
Da quanto ho letto la cosa dovrebbe funzionare anche per gli utenti che
hanno accesso al serv^Wdesktop da remoto.
Ciao,
Alessandro Topo Galileo
> Questa cosa non l'ho mai capita: basta attendere che prima o poi
> l'utente legittimo utilizzi sudo e chiamarlo in un'altra stanza.
Utonto che va in un'altra stanza senza lockare il PC, se lo merita.
Alessandro Selli
Più "bleeding" che "edge".
https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00968.html
> (Hello Linux virus makers, welcome to the party).
:-(
Ciao,
Santo Capolozo
> Se hai accesso fisico alla macchina non c'e' password che tenga.
Mica vero, se il disco � criptato l'accesso fisico alla macchina non
serve a nulla.
Ora le varie *buntu propongo la cifratura del disco che comunque non ha
influenza su questo argomento.
Basta che il pc sia acceso, una scusa per l'utonto la si trova...
E lui ignaro.
> E se hai accesso fisico all'utente ancora meno.
LOL.
Santo Capolozo
> Da quanto ho letto la cosa dovrebbe funzionare anche per gli utenti
> che hanno accesso al serv^Wdesktop da remoto.
Io sul serio attendo che qualcuno mi spieghi perch� non hanno impostato
timestamp_timeout=0 di default.
Se mi risponde che � stato fatto per comodit� temo che lo mander� a quel
paese.
Quasimodo
#mode SONO_UN_SEMPLICIOTTO On
Se io cripto un disco, la "password" di decrittazione la devo scrivere
da qualche parte nel sistema, altrimenti le applicazioni come leggono il
disco (a meno di usare applicazioni che sfruttano una doppia chiave, in
cui la seconda � cablata nel software)?
E se la "password" � scritta nel sistema, chi ha accesso al sistema vede
i file in chiaro, quindi la crittazione non serve ad un beato nulla.
Se invece cripto una directory e la apro "on demand" tramite immissione
della password, tale protezione pu� essere applicata solo ai sistemi
desktop, dove l'utente si collega.
Quindi, criptare un disco di un server ha senso solo se si tratta di un
disco rimovibile.
#mode SONO_UN_SEMPLICIOTTO Off
Che dite, cambio pusher o il mio ragionamento fila?
Hermooz
wrote:
> Io sul serio attendo che qualcuno mi spieghi perché non hanno impostato
> timestamp_timeout=0 di default.
Perchè non serve a niente?
Lo scenario "distraggo l'utente e uso il PC a sua insaputa" non regge
granchè e soprattutto non è con quel settaggio che si può
controbattere, ma con lock dello schermo, formazione degli utenti,
ecc. ecc.
bye!
Vide
> Da quanto ho letto la cosa dovrebbe funzionare anche per gli utenti che
> hanno accesso al serv^Wdesktop da remoto
Su questo hai capito male. È attivo solo per gli utenti locali.
--
Vide
Luca Bertoncello
> #mode SONO_UN_SEMPLICIOTTO On
> Se io cripto un disco, la "password" di decrittazione la devo scrivere
> da qualche parte nel sistema, altrimenti le applicazioni come leggono il
> disco (a meno di usare applicazioni che sfruttano una doppia chiave, in
> cui la seconda � cablata nel software)?
> E se la "password" � scritta nel sistema, chi ha accesso al sistema vede
> i file in chiaro, quindi la crittazione non serve ad un beato nulla.
> Se invece cripto una directory e la apro "on demand" tramite immissione
> della password, tale protezione pu� essere applicata solo ai sistemi
> desktop, dove l'utente si collega.
> Quindi, criptare un disco di un server ha senso solo se si tratta di un
> disco rimovibile.
> #mode SONO_UN_SEMPLICIOTTO Off
> Che dite, cambio pusher o il mio ragionamento fila?
Cambia pusher!
E guardati quest'articolo: http://www.soft-land.org/articoli/artlb02
Ciao
Luca Bertoncello
(luca...@lucabert.de)
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
Santo Capolozo
> Lo scenario "distraggo l'utente e uso il PC a sua insaputa" non regge
> controbattere, ma con lock dello schermo, formazione degli utenti,
> ecc. ecc.
Il punto �: perch� creare un potenziale problema di sicurezza, aprendo
una (inutile) finestra temporale?
Per "comodit�"??
Il bello � che tale periodo non pu� essere terminato anticipatamente;
per un quarto d'ora la password praticamente non esiste.
Agli amanti dell'ingegneria sociale il modo di sfruttare questa che, a
mio avviso, � una vulnerabilit�.
Santo Capolozo
> Hemmm... no, l'idea e' che il disco e' criptato e per essere "montato"
> ha bisogno di una password che deve essere digitata al momento del boot.
No, ma lui stava scherzando.
Veroo?
mallin.shetland
> Io sul serio attendo che qualcuno mi spieghi perché non hanno impostato
> timestamp_timeout=0 di default.
L'utilità di sudo si vede quando c'è più di un amministratore che magari
hanno compiti diversi. Qui sudo da il meglio di sé. Per esempio ad alcuni
permette solo di amministrare i database, ad altri solo il sistema di
stampa, ad altri di collegarsi come root. Ma il vero punto di forza è la
tracciabilità: sudo permette di sapere chi ha fatto, cosa ha fatto e quando
lo ha fatto. L'impattto positivo sulla sicurezza rispetto ad attacchi
interni è evidente; un amministratore infedele non farà niente di
compromettente sapendo di essere osservato. Ovviamente perché questo
funzioni l'accesso come root deve essere limitato ad una sola persona e
ovviamente tutto questo è inutile e troppo complicato su un semplice
desktop.
In questa ottica può avere un senso un timeout non nullo
Santo Capolozo wrote:
> Se mi risponde che é stato fatto per comodità temo che lo manderò a quel
> paese.
Una dei pochi motivi validi per impostare un timeout non nullo è che
digitare spesso la password aumenta enormemente la possibilità di
essere spiati.
PS no neanche io ci credo. ;-)
Santo Capolozo
> ovviamente tutto questo è inutile e troppo complicato su un semplice
> desktop.
Siamo d'accordo, tuttavia stiamo parlando di un prodotto _molto_
orientato al Desktop...
Non è l'uso di sudo in discussione ma la finestra temporale.
> Una dei pochi motivi validi per impostare un timeout non nullo è che
> digitare spesso la password aumenta enormemente la possibilità di
> essere spiati.
>
> PS no neanche io ci credo. ;-)
Grazie per l'impegno :) ma attendo un'altra giustificazione! :)
Vide
> Non è l'uso di sudo in discussione ma la finestra temporale.
La finestra temporale è per comodità, perchè se stai aggiornando il sistema
per esempio ti chiederebbe 3 volte almeno la password nello spazio di poco
tempo.
Se con igegneria sociale riesci a far introdurre remotamente la password
al'utente una volta, ci riesci anche per fare eseguire il tuo malware.
--
Vide
mallin.shetland
> Siamo d'accordo, tuttavia stiamo parlando di un prodotto _molto_
> orientato al Desktop...
Credo di essere stato chiaro in questo in questa occasione ed anche
in precedenza: sudo su un desktop serve a poco e niente, figuriamoci
se serve impostare un timeout su sudo.
Santo Capolozo wrote:
> Non è l'uso di sudo in discussione ma la finestra temporale.
Qui forse sono stato poco chiaro facendo una premessa molto
lunga per poi dare una risposta molto sfuggente. Rimedio subito.
La finestra temporale di sudo serve agli aiutanti dell'amministratore
ad avere al comodità di una shell di root senza avviare una shell
di root e senza fare troppi danni.
Naturalmente rimane sempre la possibilità di fare sudo bash o
sudo su ma in tal caso l'amministratore indisponente verrà
immediatamente individuato, preso per la collottola, trascinato
davanti alla santa inquisizione e LARTato a dovere.
Santo Capolozo wrote:
> Grazie per l'impegno :) ma attendo un'altra giustificazione! :)
Aspetterai a lungo. Non esiste nessuna giustificazione valida
per usare sudo su deskop.
whiplash
> ovviamente tutto questo è inutile e troppo complicato su un semplice
> desktop.
>
> In questa ottica può avere un senso un timeout non nullo
Quoto.
November
> Il bello � che tale periodo non pu� essere terminato anticipatamente;
> per un quarto d'ora la password praticamente non esiste.
E qui un RTFM ci sta tutto.
Santo Capolozo
> La finestra temporale è per comodità, perchè se stai aggiornando il sistema
> per esempio ti chiederebbe 3 volte almeno la password nello spazio di poco
> tempo.
Non hai letto il mio messaggio precedente, stai rischiando di farti un
viaggio gratis! (Oh, si scherza, eh!)
Lo ripeto per l'ennesima volta (sembra di essere su icod).
Piuttosto abiliti root e/o imposti a zero il timeout di sudo.
Se mi allontano dal PC con un terminale che mostra "#" sono un fesso ma
basta chiudere la shell e non corro rischi, idem per sudo se timeout=0.
Se mi allontano dal PC a cui ho appena fatto eseguire sudo con
timeout=15, anche se chiudo la shell _chiunque_ a questo mondo si
avvicini alla tastiera può diventare root.
Io la chiamerei *temporary_local_privilege_escalation* così, con il suo
nome, qualcuno potrebbe capacitarsene.
> Se con igegneria sociale riesci a far introdurre remotamente la password
> al'utente una volta, ci riesci anche per fare eseguire il tuo malware.
Veramente sono solo io così paranoico?
Un conto è convincere, in qualche modo, un utente a lanciare un malware,
instillandogli comunque del dubbio, un altro conto è invece non avere
bisogno dell'utente perché per un quarto d'ora non esiste nessuna password.
E l'utente non ha nessun dubbio, resta ignaro.
Quasimodo
> On 2009-11-19, Quasimodo <lavoro....@ajquaglia.toglimi.it> wrote:
>> #mode SONO_UN_SEMPLICIOTTO On
>>
>> Se io cripto un disco, la "password" di decrittazione la devo scrivere
>> da qualche parte nel sistema, altrimenti le applicazioni come leggono il
>> disco
>
> ha bisogno di una password che deve essere digitata al momento del boot.
>
> quando fai partire Apache.
>
> Una volta che la macchina e' partita il disco e' montato e viene letto
> dal sistema. *Ovviamente*, se la macchina viene spenta la password
> dovrebbe essere ri-digitata per poterla avviare. Questo si fa' per
> evitare il sistema semplice di riavviare e mandare la macchina in
> single-user-mode o avviare con una live e poi montare il disco fisso e
> guardarci dentro.
>
> Ovviamente le possibilita' che la password sia persa o che quello che la
> sa non sia li' quando ti serve di avviare la macchina nel mondo reale
> sono abbastanza elevate.
>
> Davide
>
Appunto, intendevo quello: ho un server presso un cliente, e quello
vuole poterlo riavviare quando gli pare, se cripto la partizione devo
anche dargli la passphrase, altrimenti mi tocca essere la' ogni volta...
In puro spirito 'Storie della Sala Macchine' il CL di questo progetto
voleva criptare anche il login (perch� non abbiamo ben chiaro cosa vuol
fare il cliente con un nostro software), poi ero riuscito a farlo
desistere... anche perch�, se il cliente vuole la password di root, per
riavviare un SUO server ...
Santo Capolozo
> E qui un RTFM ci sta tutto.
Gi� perch� secondo te timestamp_timeout da dove esce?
Ho gi� detto che questa a mio avviso � una soluzione sufficiente ma NON
applicata.
Stiamo parlando di Ubuntu e di utonti.
Non mi dire che all'utente basta lanciare visudo e configurarsi i
privilegi perch� siamo completamente fuori dalla mia osservazione
iniziale (ed � anche una cosa al di fuori della portata dell'utente o
quantomeno non di sua competenza).
Altrimenti si installerebbe una Debian :)
Quindi, e qui mi spiego meglio, *per l'utente medio di Ubunutu* non c'�
modo di chiudere la finestra temporale, nemmeno chiudendo la shell;
insomma, non � colpa sua.
November
> November ha scritto:
>> E qui un RTFM ci sta tutto.
>
> Gi� perch� secondo te timestamp_timeout da dove esce?
Da man sudoers, non da man sudo.
mallin.shetland
> Lo ripeto per l'ennesima volta (sembra di essere su icod).
Eppure è chiaro a tutti.
Se un utonto si dovesse allontanare momentaneamente dal computer allora
userà lock vlock xlock o sarcazzo.
Il timeout di sudo non c'entra una mazza.
Santo Capolozo wrote:
> Se mi allontano dal PC con un terminale che mostra "#" sono un fesso ma
> basta chiudere la shell e non corro rischi, idem per sudo se timeout=0.
> Se mi allontano dal PC a cui ho appena fatto eseguire sudo con
> timeout=15, anche se chiudo la shell _chiunque_ a questo mondo si
> avvicini alla tastiera può diventare root.
> ...
Non ti seguo. Se stai in un terminale ^D se stai sotto X ctrl-alt-bksp
ripetuti per ogni terminale e per ogni sessione grafica. Non è meglio usare
xlock? E poi anche se adotti la tua molto drastica soluzione, dopo tu od
un'altro utonto sarà costretto a loggarsi di nuovo. Dove sta il pericolo?
Santo Capolozo
> Da man sudoers, non da man sudo.
Io spero che tu non ti stia riferendo a sudo -k.
Primo perch� nessun utente lo conosce (puoi fidarti), secondo perch� �
un meccanismo volontario e non automatico (al contrario del timeout) e
nessuno sente il bisogno di lanciarlo, tanto pi� che va eseguito da
terminale (e gli utenti se possono evitano la shell).
Se fosse paranoico farebbe come io insisto a dire o alla peggio farebbe
come insiste a dire mallin.shetland, bloccando la sessione.
Ma � un utente. E la vulnerabilit� locale resta, anche se non per colpa sua.
Santo Capolozo
> Se un utonto si dovesse allontanare momentaneamente dal computer allora
> userà lock vlock xlock o sarcazzo.
> Il timeout di sudo non c'entra una mazza.
C'entra la volontarietà/automatismo dell'azione.
Per non ripetermi vedi la risposta scritta a November.
November
> November ha scritto:
>> Da man sudoers, non da man sudo.
>
> Io spero che tu non ti stia riferendo a sudo -k.
Fino ad ora hai detto che non � possibile annullare il timeout o far in
modo che venga revocato il permesso chiudendo il terminale, sudo -k ti
smentisce, n� pi� n� meno.
> Primo perch� nessun utente lo conosce (puoi fidarti), secondo perch� �
> un meccanismo volontario e non automatico (al contrario del timeout) e
> nessuno sente il bisogno di lanciarlo,
Io in casa mia non sento nessun bisogno di bloccare nulla, non corro
nessun pericolo. Come la mettiamo?
> Se fosse paranoico farebbe come io insisto a dire o alla peggio farebbe
> come insiste a dire mallin.shetland, bloccando la sessione.
Che � quello che logicamente fanno tutti, ma non solo per via di sudo.
A volte il problema risiede addirittura nel fatto che non si pu� nemmeno
lasciare l'hw incustodito (ad es. un portatile).
Andrea B. @wrk
sudo con timeout = 0 � inutile poich� assai raramente ti capita di dover
eseguire un singolo comando. Essendo ubuntu un sistema ritagliato per il
desktop si evita con sudo che l'utente tenda a utilizzare il sistema
sempre come root. Sudo � meno utile per la versione server in piccole
realt� dove, quasi sempre, si accede per effettuare operazioni che
richiedono l'accesso come root senza prevedere autorizzazioni diverse
per le varie parte del sistema, vero � che basta sudo su e sei root.
A me sembra una scelta logica.
Hermooz
wrote:
> Il punto è: perché creare un potenziale problema di sicurezza, aprendo
> una (inutile) finestra temporale?
> Per "comodità"??
> Il bello è che tale periodo non può essere terminato anticipatamente;
> per un quarto d'ora la password praticamente non esiste.
> Agli amanti dell'ingegneria sociale il modo di sfruttare questa che, a
> mio avviso, è una vulnerabilità.
Aridaje. Ma dove sta la vulnerabilità? Come ti ho già accennato, il
fatto che ci sia questa finestra temporale non modifica minimamente lo
schema dei privilegi e quello dei rischi. Se l'utente lascia il PC
incustodito con una sessione aperta il problema c'e', ma non è
relativo a sudo e non è con sudo che va risolto.
bye!
Santo Capolozo
> Fino ad ora hai detto che non � possibile annullare il timeout o far in
> modo che venga revocato il permesso chiudendo il terminale, sudo -k ti
> smentisce, n� pi� n� meno.
Mi smentisce?
Conosco sudo -k (siamo su sys...) ma che soluzione �?
Non stai valutando correttamente il fatto che la soluzione da te citata
non modifica lo scenario tipico da me descritto in precedenza.
> Io in casa mia non sento nessun bisogno di bloccare nulla, non corro
> nessun pericolo. Come la mettiamo?
Forse delle vulnerabilit� locali il team di security se ne frega altamente?
No di certo.
Eppure ognuno � al sicuro in casa propria.
> Che � quello che logicamente fanno tutti, ma non solo per via di sudo.
Logicamente?
Santo Capolozo
> Essendo ubuntu un sistema ritagliato per il
> desktop si evita con sudo che l'utente tenda a utilizzare il sistema
> sempre come root.
A questo punto chiedo scusa ma comincio a pensare di essere io testardo
e a non capire.
Io la penso diversamente e forse qualcuno ha scritto una motivazione
valida ma io non l'ho afferrata.
ValeRyo Saeba
messaggio news:4b053025$0$6835$5fc...@news.tiscali.it
> A questo punto basta da utente non privilegiato un "sudo su" seguito
> da "passwd" per abilitare root a proprio piacimento e per usi
> futuri...
Se hai le "competenze" per fare sudo su e passwd per usi futuri, sei
anche in grado di riavviare (quando ti servir�) con init=/bin/bash oppure
con una live (anche meglio).
> Perch� quelli di Ubuntu non impostano di default timestamp_timeout=0 ?
Perch� (l'hanno scritto altri, e io concordo) se devi fare sudo su un
desktop
probabilmente ne devi fare tre o quattro.
Ed � comodo non inserirla tre/quattro volte, altrimenti quando l'utente deve
installare qualcosa gli pu� pure venire il ghiribizzo di entrare
direttamente
come root, poi visto che c'� si mette a navigare, sente un po' di musica
e cos� via.
--
ValeRyo
XT600 "Katoki Pajama" - http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - http://www.slimmit.com/go.asp?7X0
GamerTag: http://card.mygamercard.net/IT/nxe/ValeRyo76.png
November
> November ha scritto:
>> Fino ad ora hai detto che non � possibile annullare il timeout o far
>> in modo che venga revocato il permesso chiudendo il terminale, sudo -k
>> ti smentisce, n� pi� n� meno.
>
> Mi smentisce?
> Conosco sudo -k (siamo su sys...) ma che soluzione �?
Io non ho proposto una soluzione, anche perch� per trovare una soluzione
ad un problema bisogna prima individuare il problema (e io non ne vedo
problemi in questo caso).
Hai scritto che non � possibile fare scadere anticipatamente il timeout,
mi sono limitato a far notare che non � vero.
Vide
> Veramente sono solo io così paranoico?
Non sei paranoico, stai semplicemente facendo un minestrone di concetti.
Come diamine puoi criticare i 15 min di NOPASSWD di sudo in Ubuntu portando
come esempio "se l'utente se ne va dalla macchina, la lascia incustodita e
un altro prende accesso". Che senso ha?
Tralasciando che i più grandi danni che puoi fare a un utente li fai già COI
PERMESSI UTENTE, stai cmq tirando in ballo un vettore di attacco potresti
utilizzare al massimo per criticare che di default non si attiva lo
screensaver con il lock. Non certo per il sudo senza password.
--
Vide
Crononauta
> Tralasciando che i più grandi danni che puoi fare a un utente li fai già COI
> PERMESSI UTENTE, stai cmq tirando in ballo un vettore di attacco potresti
> utilizzare al massimo per criticare che di default non si attiva lo
> screensaver con il lock. Non certo per il sudo senza password.
Dev'essere uno di quelli che ritiene un problema di crittografia debole
quando l'utOnto appiccica un post-it allo schermo con scritta la password...
--
Massimo Bacilieri AKA Crononauta
Fr3ddie
> Il bello è che tale periodo non può essere terminato anticipatamente;
RTFM
sudo -k|K
sei un troll, PLONK!
--
Fr3ddie
fr3...@fr3ddie.it
Home Page: http://www.fr3ddie.it
OpenPGP Public Key available on my website
There are three types of people in the world:
- those who think
- those who think they think
- those who are happy to be told how to think
ordered by increasing percentage value, obviously
Santo Capolozo
> RTFM
>
> sudo -k|K
>
> sei un troll, PLONK!
Del troll ancora non me l'avevano dato...
Se ti degnavi di leggere giusto un messaggio dopo, di November, forse ti
risparmiavi di aprire il killfile.