Utente ROOT come fosse utente normale.

[sixjan]

Illuso o bla-bla non pensato!

@Mario.
Grazie per la gentilezza. L'offendere in genere e l'ultima arma di chi non ha argomenti.

@neogen

solo root può metterci un troiano in /bin/su, ma un utente normale può metterlo dove gli viene meglio... prendi l'esempio di Mario e mettici /home/utente/dove/ti/capita al posto di /usr/local/bin

Un utente normale può fare tante altre cose. Tipo scaricare un software manomesso, che al make install fa un:

Codice: Seleziona tutto

echo 'alias rm="rm -fr ~"' >> $HOME/.bashrc  

Se un utente normale, si trova un "su" nella directory corrente (io l'ho tolta da $PATH) o in qualche
altra directory di $PATH in cui può scrivere, un po' se l'è cercata. "su" può essere un troiano esattamente come "/bin/su". Punto. Senza blah blah e senza illusioni. Poi Mario fa tutto da root, quindi il rischio di essere un utente normale non lo corre mai. E la chiudo qui anche se dovesse darmi del bimbominkia. Ciao.

[Mario Vanoni]

Illuso o bla-bla non pensato!

@Mario.
Grazie per la gentilezza. L'offendere in genere e l'ultima arma di chi non ha argomenti.

@neogen

solo root può metterci un troiano in /bin/su, ma un utente normale può metterlo dove gli viene meglio... prendi l'esempio di Mario e mettici /home/utente/dove/ti/capita al posto di /usr/local/bin

Un utente normale può fare tante altre cose. Tipo scaricare un software manomesso, che al make install fa un:

Codice: Seleziona tutto

echo 'alias rm="rm -fr ~"' >> $HOME/.bashrc  

Se un utente normale, si trova un "su" nella directory corrente (io l'ho tolta da $PATH) o in qualche
altra directory di $PATH in cui può scrivere, un po' se l'è cercata. "su" può essere un troiano esattamente come "/bin/su". Punto. Senza blah blah e senza illusioni. Poi Mario fa tutto da root, quindi il rischio di essere un utente normale non lo corre mai. E la chiudo qui anche se dovesse darmi del bimbominkia. Ciao.

Non volevo offendere, chiedo scusa.

Esempio sysstat 8.1.7:
per install devi essere root perche` crea
/usr/lib/sa con 3 eseguibili,
/var/log/sa per i dati,
chiamati a loro volta da sar(1),
sia da command line che da crontab(1).

Se Sebastien Godard fosse un cattivo,
potrebbe senza problemi aggiungere un su(1)
fasullo in una directory che precede /bin.
Sono 49'922 righe di codice da guardare!

E non puoi togliere p.e. /usr/local/bin
dal PATH dell'utente, se no non trova un comando,
installato probabilmente da te.

Se /bin/su e` un troiano, biasima il sysadm,
se sei tu il sysadm, quardati in uno specchio
e pronuncia "mea culpa" a bassa voce.

[albatros]

Sì, ma il punto è che anche per installare in /usr/local/bin devi essere root e a quel punto, se quel che installi da root è codice malevolo, può succedere qualsiasi cosa, un banale falso ls in /usr/bin potrebbe fare in realtà tutt'altra cosa e avere il bit suid impostato.

[navajo]

Ragazzi, calma, non bisogna mica offendere (si) per ste cose.
però vorrei un pochino di coerenza in tutti.
Allora, a che cosa puntiamo ? alla sicurezza ? ok
mi creo un alias che punti al path giusto quando scrivo su, cosi rimango rimango vittima della mia pigrizia.
Però caro Mario, mi spieghi una cosa ?
Se dobbiamo stare attenti anche a scrivere su, per forza di cose, dovresti sostenere l uso di gnu-linux, da utente.
Se un utente potrebbe avere noia con il path di su, figuriamoci se si ha a disposizione un sistema con la shell:
LennY64:/home/navajo#

[raffaele181188]

Come hanno scritto già tanti finora, non ha senso dare /bin/su per essere sicuri. ESSERE SICURI DI COSA? Anche quello potrebbe essere software malevolo. I programmi si installano da root _TUTTI_QUANTI_. Una volta che l'hai installato sei fregato. Il controllo va fatto prima. Uno che studia software malevolo, che necessita dei permessi di root per essere installato, non lo va a mettere in /dir/strana/bin. Sicuro lo piazza in /bin, quindi dov'è l'extra-sicurezza? L'unica cosa di cui sei sicuro digitando /bin/su è che esegui /bin/su. Poi quello che fa /bin/su sono fatti suoi... Il punto è che quando installi sei root, quindi il software maligno può installarsi in una qualsiasi directory, /usr/local/bin come /bin. Root ha accesso a tutte le directory, anche /bin, quindi...

[Darkstar89]

Io non uso root solo perchè ho letto che era meglio non farlo.. Poi ho imparato a fare le cose che deve fare il root e ho capito che conviene semplicemente creare un nuovo utente per le cose giornaliere.. Comunque non credo che abbiamo bisogno di tutta questa sicurezza, con tutti i pc che ci sono perchè dovrebbero guardare propio il nostro, il ciò non cambia nel dire che bisognerebbe usare un semplice utente...
Comunque volevo sapere "script utili" per la sicurezza o per cose utili possiamo mostrarli quà, no
Incomincio io con uno script preso da pluto italia sulla pulizia di /var/log/wtmp

Codice: Seleziona tutto

#!/bin/bash
#  Cleanup, versione 3


DIR_LOG=/var/log
ROOT_UID=0     # Solo gli utenti con $UID 0 hanno i privilegi di root.
LINEE=50       # Numero prestabilito di righe salvate.
E_XCD=66       # Riesco a cambiare directory?
E_NONROOT=67   # Codice di exit non-root.


# Da eseguire come root, naturalmente.
if [ "$UID" -ne "$ROOT_UID" ]
then
  echo "Devi essere root per eseguire questo script."
  exit $E_NONROOT
fi

if [ -n "$1" ]
# Verifica se è presente un'opzione da riga di comando (non-vuota).
then
  linee=$1
else
  linee=$LINEE # Valore preimpostato, se non specificato da riga di comando.
fi


#  Stephane Chazelas suggerisce il codice seguente,
#+ come metodo migliore per la verifica degli argomenti da riga di comando,
#+ ma è ancora un po' prematuro a questo punto del manuale.
#
#    E_ERR_ARG=65   # Argomento non numerico (formato dell'argomento non valido)
#
#    case "$1" in
#    ""      ) linee=50;;
#    *[!0-9]*) echo "Utilizzo: `basename $0` file-da-cancellare"; exit\
# $E_ERR_ARG;;
#    *       ) linee=$1;;
#    esac
#
#* Vedere più avanti al capitolo "Cicli" per la comprensione delle righe
#+ precedenti.


cd $DIR_LOG

if [ `pwd` != "$DIR_LOG" ]  # o   if [ "$PWD" != "$DIR_LOG" ]
                            # Non siamo in /var/log?
then
  echo "Non riesco a cambiare in $DIR_LOG."
  exit $E_XCD
fi  #  Doppia verifica per vedere se ci troviamo nella directory corretta,
    #+ prima di cancellare il file di log.

# ancora più efficiente:
#
# cd /var/log || {
#   echo "Non riesco a spostarmi nella directory stabilita." >&2
#   exit $E_XCD;
# }




tail -n $linee messages > mesg.temp # Salva l'ultima sezione del file di
                                    # log messages.
mv mesg.temp messages               # Diventa la nuova directory di log.


# cat /dev/null > messages
#* Non più necessario, perché il metodo precedente è più sicuro.

cat /dev/null > wtmp  #  ': > wtmp' e '> wtmp'  hanno lo stesso effetto.
echo "Log cancellati."

exit 0
#  Il valore di ritorno zero da uno script

Magari sarebbe meglio spiegare quello che fa lo script.. in questo lo era già.. ciao

[Mario Vanoni]

Però caro Mario, mi spieghi una cosa ?
Se dobbiamo stare attenti anche a scrivere su, per forza di cose, dovresti sostenere l uso di gnu-linux, da utente.
Se un utente potrebbe avere noia con il path di su, figuriamoci se si ha a disposizione un sistema con la shell:
LennY64:/home/navajo#

Non ho detto che essere root e` giusto,
solo che io come sysadm ed utente lo sono sempre.

Questo non cambia niente per un utente
che, avendo la password, diventa root.

Ripeto, vecchia regola UNIX SVR2,
_mai_ usare su, sempre e solo /bin/su [-]
idem come uso sempre /sbin/lilo e non lilo.

La pigrizia venuta dalle GUI si vendica,
cliccare GUI senza conoscere cosa si clicca,
o meglio, che cosa fa la icone cliccata?

Unico virus UNIX/BSD 1988 il Morris worm,
propagato dal 23enne su macchine VAX e Sun.

[navajo]

grazie per il chiarimento Mario

[masalapianta]

_mai_ usare su, sempre e solo /bin/su [-]

perche'?

Unico virus UNIX/BSD 1988 il Morris worm,

virus e worm son due cose diverse

[Mario Vanoni]

_mai_ usare su, sempre e solo /bin/su [-]

perche'?

Unico virus UNIX/BSD 1988 il Morris worm,

virus e worm son due cose diverse

1) trattato su questo thread

2) sono sempre infezioni

[masalapianta]

_mai_ usare su, sempre e solo /bin/su [-]

perche'?

1) trattato su questo thread

ho letto di sfuggita, ma non ho trovato neanche una motivazione valida per la quale, usare /bin/su in luogo di su, possa esser piu' sicuro

virus e worm son due cose diverse

2) sono sempre infezioni

indubbiamente, ma se dici "Unico virus UNIX/BSD 1988 il Morris worm" dai ad intendere che un worm sia un virus, il che non e' vero (poi che possano essere raggruppati entrambi come malware e' fuor di dubbio, ma non sono la stessa cosa)

[Mario Vanoni]

@masalapianta

1) Rileggi

2)
Il worm del 23enne studente del MIT nel 1988
causo una infezione del piccolo mondo internet di allora,
bloccando il 10% delle macchine VAX e SUN.
Per la definizione di worm:
http://www.bellevuelinux.org/worm.html

[navajo]

domanda :
come si potrebbe manomettere il comando "su" da semplice utente ?

[Mario Vanoni]

domanda :
come si potrebbe manomettere il comando "su" da semplice utente ?

Non puoi!

Ma ogni SW che installi con root permission puo`!

E` li` il dilemma, o ti fidi della SW,
o la controlli a mano riga per riga.

[navajo]

Scusami mario per la mia ignoranza, ma allora, potrebbero avere anche ragione gli altri, quando dicono che a questo punto i controlli vanno fatti prima, e che in fondo, un lamer tanto bravo da programmare un troian del genere, per linux, conosce bene il sistema, e quindi andrebbe a modificare direttamente /usr/bin/su oppure no ?