Utente ROOT come fosse utente normale.

[masalapianta]

non rientro nel merito della discussione perche' ormai ho detto come la pensavo anche in cinese, chi poteva capire ha capito

a questo punto meglio mettere il SUID a halt per far spegnere il PC a tutti.

riguardo questo, ricordo che ormai nel 99% dei casi non ha più senso utilizzare il suid, se si ha un kernel >= 2.6.24 è mooolto piu' sicuro utilizzare le file capabilities (cap_sys_boot nel caso di halt)

[Mario Vanoni]

non rientro nel merito della discussione perche' ormai ho detto come la pensavo anche in cinese, chi poteva capire ha capito

a questo punto meglio mettere il SUID a halt per far spegnere il PC a tutti.

riguardo questo, ricordo che ormai nel 99% dei casi non ha più senso utilizzare il suid, se si ha un kernel >= 2.6.24 è mooolto piu' sicuro utilizzare le file capabilities (cap_sys_boot nel caso di halt)

Illumina per favore me ed il forum.

Codice: Seleziona tutto

root@va2:/usr/src/linux# findw CAP_SYS_BOOT
./include/linux/capability.h:291:#define CAP_SYS_BOOT         22
./kernel/kexec.c:946:   if (!capable(CAP_SYS_BOOT))
./kernel/sys.c:383:     if (!capable(CAP_SYS_BOOT))
root@va2:/usr/src/linux# 

man 7 capabilities

Codice: Seleziona tutto

...
  CAP_SYS_BOOT
              Use reboot(2) and kexec_load(2).
...

Solo kernel specifici a distro adattano questa voce ad halt(8),
senza coinvolgere reboot (Fedora, SELinux ecc.).

Dove si trova la voce in /proc?
Continuano a cambiare la locazione,
non trovo niente (maiuscolo/minuscolo) sulle mie macchine.

Con chmod 4755 /sbin/halt funziona per l'utente comune,
ma essendo /sbin/reboot un link simbolico a /sbin/halt ...

[targzeta]

Il "problema" delle capabilities è che devono essere supportate nel kernel:

Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8). The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability....

il che implica che nel kernel devono essere abilitati gli attributi estesi per i filesystem. Io nel mio kernel non li ho abilitati e mi ritorna, ad esempio per halt:

Codice: Seleziona tutto

Failed to set capabilities on file `halt' (Operation not supported)

Solo per dire che mentre il suid funziona le file capabilities potrebbero non funzionare sempre. Per il reboot si può anche utilizzare init inserendo nella inittab:

Codice: Seleziona tutto

ca::ctrlaltdel:/sbin/shutdown -t5 -r now

Per quanto riguarda la sicurezza però non saprei che dire poiché non mi viene nulla in mente, halt è un comando ben conosciuto quindi non sapendo niente a riguardo non vedo come potrebbe essere insicuro dare il suid a halt. Anzi, direi che se non è troppo OT sarei curioso di sapere il problema della sicurezza legato al suid.

Emanuele

[Mario Vanoni]

Anzi, direi che se non è troppo OT sarei curioso di sapere il problema della sicurezza legato al suid.

Emanuele, e` uguale dai tempi di UNIX.

Un programma che fa una _unica_ cosa,
senza possibilita` di fuga,
proprietario root, SUID su root, chmod 4755,
se usato in modo debito non causera` mai problemi.

Esempio pratico che funziona da 14 anni in ditta:

una directory non leggibile/scrivibile da nessuno

Codice: Seleziona tutto

d---------  2 root root   4096 2006-05-23 23:50 account

un programma prglog, proprietario root, SUID su root, chmod 4755,
per di piu` compilato in modo statico e strippato,
controllo dei programmi usati, permessi o vietati per alcuni utenti, legge

Codice: Seleziona tutto

-r--r-----  1  root root  16409 2006-05-23 11:20 allowed

nei programmi viene chiamato con system(3) all'inizio,
ma in una versione dai tempi di AT&T, definita nel *.h principale

Codice: Seleziona tutto

#define         SYSTEM(s)                  (fflush(stdout), system(s)

controllo completo quante volte un utente usa un programma,
controllo dei furbi che, pur sapendolo, riprovano programmi a loro vietati.

Senza SUID molto difficile da governare.

[Mario Vanoni]

Emanuele, ero certo, ma l'ho riprovato per sicurezza.

rm -iv /sbin/reboot
cp -aiv /sbin/halt /sbin/reboot
chmod 4755 /sbin/halt

Da utente normale, _non_ _root_:
reboot: must be superuser
halt lo esegue perfettamente.

[masalapianta]

Illumina per favore me

difficile

ed il forum.

questo è gia più fattibile:
dal kernel 2.6.24 sono state introdotte in linux le file capabilities, che sono come le vecchie capabilities (piu' alcune aggiunte) ma si applicano ai singoli binari (anzichè valere a livello globale); man capabilities, man setcap, man getcap forniscono tutte le indicazioni del caso

[masalapianta]

Il "problema" delle capabilities è che devono essere supportate nel kernel:

Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8). The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability....

il che implica che nel kernel devono essere abilitati gli attributi estesi per i filesystem. Io nel mio kernel non li ho abilitati e mi ritorna, ad esempio per halt:

Codice: Seleziona tutto

Failed to set capabilities on file `halt' (Operation not supported)

bhe ormai la quasi totalità delle distribuzioni adotta kernel precompilati con versione superiore alla 2.6.24 e con abilitati gli xattr; riguardo slackware non saprei ma, da quel che leggo sul forum, quasi nessuno si tiene il precompilato che viene di default quindi, anche se non avesse abilitati gli xattr, basta abilitarli quando si compila un nuovo kernel

Per quanto riguarda la sicurezza però non saprei che dire poiché non mi viene nulla in mente, halt è un comando ben conosciuto quindi non sapendo niente a riguardo non vedo come potrebbe essere insicuro dare il suid a halt. Anzi, direi che se non è troppo OT sarei curioso di sapere il problema della sicurezza legato al suid.

halt è solo uno degli innumerevoli esempi; comunque i rischi di sicurezza sono tutti quelli legati al dare permessi di root a qualsivoglia processo (ad esempio un buffer overflow sfruttabile utilizzando i parametri passati sulla riga di comando)

[masalapianta]

Anzi, direi che se non è troppo OT sarei curioso di sapere il problema della sicurezza legato al suid.

Emanuele, e` uguale dai tempi di UNIX.

Un programma che fa una _unica_ cosa,
senza possibilita` di fuga,
proprietario root, SUID su root, chmod 4755,
se usato in modo debito non causera` mai problemi.

questa è una gigantesca menzogna; qualunque programmino che fa una singola cosa, se setuid root, può costituire un gigantesco buco di sicurezza; gli esempi sono millemilamiliardi e ne escono quotidianamente.
Queste banalità le conoscono anche i "sistemisti un tanto al kg", l'ignoranza è un diritto ma non lo è il fare disinformazione; quindi per l'ennesima volta, se di un argomento hai una scarsa o nulla conoscenza, ti rinnovo l'invito a tacere, piuttosto che a dire corbellerie che qualche novizio potrebbe prendere per buone.

[Mario Vanoni]

Guardate questo punto di vista, in inglese
http://tuxteam.com/2010/07/30/why-the-r ... overblown/
e giudicate Voi se come utenti unici sulla macchine quanto rischiate.

[targzeta]

Beh, l'articolo termina con:

...
In short, if you want to run as root on your desktop, go for it. But know the risks, and know the consequences. On the other hand, don’t chant “don’t login as root” as if it’s a magic bullet for security.

Che mi sembra ben lontano dal dire: "loggatevi sempre e solo come utente root", no?

Emanuele

[Mario Vanoni]

Beh, l'articolo termina con:

...
In short, if you want to run as root on your desktop, go for it. But know the risks, and know the consequences. On the other hand, don’t chant “don’t login as root” as if it’s a magic bullet for security.

Che mi sembra ben lontano dal dire: "loggatevi sempre e solo come utente root", no?

Emanuele

La quintessenza e` che sei un utente _unico_ consapevole di quello fai,
non ha senso di usare un utente qualunque ed ogni volta che serve, "sudare"!
Time is money, anche come utente singolo.

[targzeta]

...
Time is money, anche come utente singolo.

Appunto, fai un errore come utente root e poi vedi quanto tempo perderai in più...e quanto dovrai sudare di più . Un po' come quelli che vanno a 150 all'ora per arrivare prima, poi si fracassano contro un muro ed arrivano più tardi. Il rischio non ha senso secondo me.

Emanuele

[navajo]

Beh, l'articolo termina con:

...
In short, if you want to run as root on your desktop, go for it. But know the risks, and know the consequences. On the other hand, don’t chant “don’t login as root” as if it’s a magic bullet for security.

Che mi sembra ben lontano dal dire: "loggatevi sempre e solo come utente root", no?

Emanuele

La quintessenza e` che sei un utente _unico_ consapevole di quello fai,
non ha senso di usare un utente qualunque ed ogni volta che serve, "sudare"!
Time is money, anche come utente singolo.

aia non so come ma solo ora mi rendo conto che è stato postato solo il quote e non la risposta..
volevo solo dire che almeno nell utenza desktop, una volta preparato il pc come si vuole, con i programmi necessari, se non ci sono esigenze particolari,
e almeno per mia esperienza, ci si logga come root appena acceso il pc, si controllano eventuali aggiornamenti di sicurezza, e si ritorna utenti normali.
Il tutto non ruba neanche 5 minuti, e ci tiene al riparo da eventuali caXXate che capita di fare, perché, anche se sei il miglior ROOT del mondo, sempre umano sei ,e almeno una volta nella vita ti capita di sbagliare..
Quindi come dici spina, che senso ha andare a 150 kmh rischiando di fracassarsi le ossa ??'

[conraid]

ogni tanto fa bene fare del movimento e sudare, ti tiene in forma

[hashbang]

sinceramente non vedo il motivo di usare root.....se non per installare programmi o fare un ritocchino alle configurazioni di sistema o per la compilazione di un kernel....io uso sempre utenti normali, poi se proprio devo mi loggo come root con "su", faccio quello che devo fare e poi torno come utente normale. È vero che se sei un utente esperto potresti anche farne a meno, però è sempre meglio che l'amministratore non venga usato troppo se non per necessità (Windows docet ). Anche perchè, questo è un mio pensiero, in caso di falle nella sicurezza se usi sempre e solo root sei molto più vulnerabile. Preferisco perdere 5 minuti in più, e guadagnare in sicurezza