Newsgroup: it.comp.os.linux.sys
Titolo: Fangala! Fedora12 rende di default gli utonti dei simil-superutenti

   Il packagekit di freedesktop nella Fedora12 permette di default agli 
utenti non privilegiati di installare qualsiasi pacchetto firmato nei 
repository senza dover inserire la password di root:
http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-Lets-Users-Install-Signed-Packages-Sans-Root-Privileges
   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

 (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

 
Bellino! Almeno ubuntu consente solo agli utenti del gruppo admin di
usare sudo.

 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?

 Se hai accesso fisico alla macchina non c'e' password che tenga.
   Da quanto ho letto la cosa dovrebbe funzionare anche per gli utenti che 
hanno accesso al serv^Wdesktop da remoto.
   Ciao,


 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.

 (Hello Linux virus makers, welcome to the party).
:-(
   Ciao,


 E se hai accesso fisico all'utente ancora meno.
LOL.

 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.

Santo Capolozo ha scritto:

#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?

 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!

 hanno accesso al serv^Wdesktop da remoto
Su questo hai capito male. È attivo solo per gli utenti locali.
-- 
Vide

 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

 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�.

 ha bisogno di una password che deve essere digitata al momento del boot.
No, ma lui stava scherzando.
Veroo?

 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. ;-) 

 PS no neanche io ci credo. ;-) 
Grazie per l'impegno :) ma attendo un'altra giustificazione! :)

 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

 Grazie per l'impegno :) ma attendo un'altra giustificazione! :)
Aspetterai a lungo. Non esiste nessuna giustificazione valida 
per usare sudo su deskop.

 In questa ottica può avere un senso un timeout non nullo
Quoto.

 per un quarto d'ora la password praticamente non esiste.
E qui un RTFM ci sta tutto.

 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.

 
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 ...

 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.

 Gi� perch� secondo te timestamp_timeout da dove esce?
Da man sudoers, non da man sudo.

 ...
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?

 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.

 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.

 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).

Santo Capolozo ha scritto:

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.

 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!

 Che � quello che logicamente fanno tutti, ma non solo per via di sudo.
Logicamente?

 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.

 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
 

 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.

 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

 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

 per un quarto d'ora la password praticamente non esiste.
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

 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.