[RISOLTO]Passare da root a user

[ponce]

per aggiungerlo ai gruppi che danno la comodita' d'utilizzo basta creare l'utente con adduser e quando chiede a che gruppi aggiungerlo premere la freccia in alto (comunque adduser te lo dice).

[conraid]

tanta fatica fare un nuovo login?

Per te sembra di sì visto che vuoi tenere sempre root, io mi loggo come root o come conraid a seconda di cosa devo fare.

vai a "sudare" per cambiare qualcosa nel sistema?

su != sudo
sono utility diverse e sono anche in pacchetti diversi

[twister]

Ma tu vuoi fare un utente non root che ha i "poteri" di root? Che senso ha? Se dall'utente puoi fare con successo un rm -rf / allora rimani root, tanto le cretinate le faresti uguale.
Studia un po e vedrai che problemi di permessi e altro non troverai.
Se ti pesano le mani per dare puoi un su...

[Mario Vanoni]

tanta fatica fare un nuovo login?

Per te sembra di sì visto che vuoi tenere sempre root, io mi loggo come root o come conraid a seconda di cosa devo fare.

vai a "sudare" per cambiare qualcosa nel sistema?

su != sudo
sono utility diverse e sono anche in pacchetti diversi

Ho scritto "sudare" per dire /bin/su - alla UNIX oppure sudo alla Debian.


Q: Quanti utenti normali scaricano e bruciano KNOPPIX 6.0 oggi?
A: Nessuno, ignorano cosa sia.

Q: Perche` K3b ti rimprovera di essere root?
A: Deduce che il sysadm e` un utonto pericoloso.

Q: Perche` growisofs da shell non reclama che sei root?
A: Perche` solo un utonto pazzo puo` usare la shell ...

...

[masalapianta]

L'utente root non è un utente, è solo una schermata dietro cui l'utonto si mette al riparo solo dalle cazzate che lui stesso potrebbe fare.

Sono sempre root da >23 anni, mai un virus o simili.

Se sai quello che fai e se sei diffidente/prudente,
senza cliccare alla Figaro del Barbiere di Rossini,
sopravvivi 23 anni senza problemi.

mio nonno ha fumato come un turco per decenni e non ha mai avuto cancro o enfisemi o malattie cardiopolmonari che di solito si associano agli effetti del fumo; da questo deduciamo che fumare non fa male? Oppure abbiamo sufficiente grano salis, per capire che la nostra singola esperienza, non costituisce una base statistica abbastanza ampia, ne tantomeno rappresentativa, da poterci basare sopra una teoria?
Il problema, quando si fa tutto da root, non e' solo quello dei virus/trojan o di fare casini per inesperienza, ma anche di utilizzare applicazioni buggate che, nel caso peggiore, possono permettere a malintenzionati l'esecuzione remota di codice; sotto questo punto di vista non conta una fava l'esperienza e la bravura dell'utente, se ad esempio c'e' uno 0day su un bug non noto in un pezzo di codice che usa firefox per la gestione delle immagini jpeg, tu utente espertissimo/bravissimo/fighissimo/daventitreanniusorootemaiunproblema vai sul forum di slacky.eu e visualizzi un post il cui avatar e' una jpeg creata ad hoc per sfruttare un bufferoverflow del pezzo di codice di cui sopra facendo eseguire del codice malevolo come root al tuo firefox

[ponce]

non so se ricordate la backdoor nel Makefile di openssh di qualche anno fa.

[masalapianta]

Ho scritto "sudare" per dire /bin/su - alla UNIX oppure sudo alla Debian.

debian di default non usa sudo per la gestione del sistema (esattamente come slackware)

Q: Perche` K3b ti rimprovera di essere root?
A: Deduce che il sysadm e` un utonto pericoloso.

no, perche' k3b e' solo un frontend per altri programmi e vale il principio che tanto meno codice gira con euid 0 e tanto meno il sistema e' insicuro (quindi a girare con euid 0 sara' solo il processo che si occupa della masterizzazione, quindi cdrecord,cdrdao,ecc.. e non tutto il frontend grafico)

Q: Perche` growisofs da shell non reclama che sei root?
A: Perche` solo un utonto pazzo puo` usare la shell ...
...

no, perche' e' auspicabile far girare come root un software di masterizzazione (ricordo che k3b non lo e', al contrario di growisofs) affinche' possa alzare la propria priorita' di scheduling

[Mario Vanoni]

Il problema, quando si fa tutto da root, non e' solo quello dei virus/trojan o di fare casini per inesperienza, ma anche di utilizzare applicazioni buggate che, nel caso peggiore, possono permettere a malintenzionati l'esecuzione remota di codice; sotto questo punto di vista non conta una fava l'esperienza e la bravura dell'utente, se ad esempio c'e' uno 0day su un bug non noto in un pezzo di codice che usa firefox per la gestione delle immagini jpeg, tu utente espertissimo/bravissimo/fighissimo/daventitreanniusorootemaiunproblema vai sul forum di slacky.eu e visualizzi un post il cui avatar e' una jpeg creata ad hoc per sfruttare un bufferoverflow del pezzo di codice di cui sopra facendo eseguire del codice malevolo come root al tuo firefox

Un sysadm che valga questa qualificazione,
non mette SW incerta sul sistema.
Kernel 2.6.28.1 secondo LKML e` buggy.
Greg KH ha pubblicato il 2.6.28.2,
se lo usi rischi, aspetta almeno 2.6.28.3.

Sei su un sistema UNIX che non conosci,
non ha ne more(1) ne less(1), solo pg(1).
Usa vi(1) ed esci ogni volta con
:q!
e non creerai mai problemi, ma leggi il file!

C'est la`, la petite difference entre
un sysadm ed un ut[eo]nt[eo] con permessi root.

[ponce]

mario, pero' non tieni di conto dei bachi su software considerati "sicuri", come l'esempio di openssh citato prima.

[conraid]

mario, pero' non tieni di conto dei bachi su software considerati "sicuri", come l'esempio di openssh citato prima.

o di macchine aperte al pubblico, per esempio con login ssh, dove è bene loggarsi come utente e fare su, invece che permettere il login da root

[Mario Vanoni]

mario, pero' non tieni di conto dei bachi su software considerati "sicuri", come l'esempio di openssh citato prima.

Se leggi l'articolo Heise, in tedesco,
coinvolgeva openBSD, ma non FreeBSD,
usando Slackware, molto conservatore,
non ti toccava affatto.

Quindi citazione molto utile ...

[puzuma]

i motivi per cui usare un utente con priviliegi limitati sono sia pratici che di sicurezza, ad esempio:

- praticità: posso montare le home con i dati degli utenti in una partizione diversa semplificando backup e manutenzione del sistema

- sicurezza: i sistemi linux, seppur intrisecamente più sicuri dei sistemi windows, non sono esenti da bachi: i più gravi (che comunque capitano ...) possono permettere ad un eventuale attaccante di aquisire i privilegi dell'utente loggato in quel momento, se sei root ti possono installare qualsiasi cosa e neanche te ne accorgi, se sei un utente vivi felice.


del resto non vedo quali limitazioni ci siano ad usare un utente "normale", lavoro tutto il giorno così e non ho nessun problema, quando devo fare manutenzione al sistema apro una shell e mi loggo come root (del resto l'utente root è nato ed è stato pensato fin dal primo giorno del primo unix solo come utente di amministrazione del sistema, ogni altro uso significa andare contro il progetto iniziale).

per migrare da un utente ad un altro puoi semplicemente procedere così:

Codice: Seleziona tutto

# cp -r /root/* /home/utente/
# chown -R utente.users /home/utente/

in questo modo ti ritrovi tutti i settaggi, i dati e tutto migrato in un attimo. Poi se riscontri altri problemi posta qua che ti aiutiamo, vedrai che non c'è niente di drammatico.

[ponce]

mario, mi sembrava chiaro: il senso e' che se la backdoor e' in un sorgente ti fottono perche' nessuno si controlla tutte le righe del configure/makefile.

e i sorgenti sono maneggiati spesso da chi usa slackware.

poi che quella versione con backdoor sia stata scaricata solo 200 volte dai server di openbsd perche' tripwire ha fatto il suo lavoro e' relativo.
se ricordi hanno craccato anche i server di sourceforge e debian...

in quel caso dando un semplice make da root, l'attaccante avrebbe avuto la shell aperta.

[Mario Vanoni]

mario, mi sembrava chiaro: il senso e' che se la backdoor e' in un sorgente ti fottono perche' nessuno si controlla tutte le righe del configure/makefile.

e i sorgenti sono maneggiati spesso da chi usa slackware.

poi che quella versione con backdoor sia stata scaricata solo 200 volte dai server di openbsd perche' tripwire ha fatto il suo lavoro e' relativo.
se ricordi hanno craccato anche i server di sourceforge e debian...

in quel caso dando un semplice make da root, l'attaccante avrebbe avuto la shell aperta.

Se usi, p.e. OpenSSH 3.4p1, un patch level esperimentale.

Esperimenti e rischi ... portati le conseguenze.

Cosa _mai_ fatta sulle production machines.

[Redwave]

wow ho fatto un vero casino con questo mio topic, beh devo dire grazie a tutti, che sicuramente siete più esperti di me, ora non so provo un pò questo limitato e vedo.
comunque grazie a tutti delle numerose risposte.
ciao.