sudo con e senza password, sudo su shell script

Ciao,

quali sono i pro e i contro di dare il sudo su certi comando con o senza
password? Dato che e' la mia password ... io la so :wink:
I casi che mi vengono in mente sono che con la password ev. un programma
non lo puo' fare in autonomia (senza che noi lo sappiamo o con il
nostro consenso)
o se mi dimentico la shell aperta un'altra
persona (dopo un po' di tempo) non puo' piu' usare sudo. E' corretto
o ci sono altri pro e contro?

Seconda cosa, invece che dare i diritti di sudo su un programma come
init, o mount, o addirituttura su tutto, secondo voi e' meglio che io
credo degli script di shell
come shutdown.sh o mount.sh piu' specifici x certi tipi di operazioni
e do i diritti di sudo a quelli piuttosto che a comandi generici che
possono essere utilizzati anche per altri scopi?

Qualcuno di voi usa sudo senza password x qualche operazione?

Rispondo ad un thread vecchio...

Davide wrote:

quali sono i pro e i contro di dare il sudo su certi comando con o senza
password? Dato che e' la mia password ... io la so :wink:

oltre ai tuoi esempi c'e' un'altro: quando non sono superutente, sono
molto meno cauto a lanciare programmi che non conosco esattamente. Per
esempio hai scaricato un programma, fai il 'make all' ed il programmatore
ha deciso che 'all' fa anche il 'make install' allora preferisci essere
notificato che il sistema sta per essere modificato.

secondo voi e' meglio che io credo degli script di shell [..]
e do i diritti di sudo a quelli piuttosto che a comandi generici che
possono essere utilizzati anche per altri scopi?

Secondo me e' troppo lavoro e troppo poco flessibile. Tanto con sudo puoi
anche specificare gli argomenti consentiti per ogni comando.

Qualcuno di voi usa sudo senza password x qualche operazione?

Personalmente no, perche' preferisco essere ricordato che sto facendo
un'operazione che richiede poteri di superutente.

Thomas

Davvero? Come?

Ho trovato la risposta da solo nella man page :wink:

ALL CDROM = NOPASSWD: /sbin/umount /CDROM,\
               /sbin/mount -o nosuid\,nodev /dev/cd0a /CDROM

Any user may mount or unmount a CD-ROM on the machines in the CDROM
Host_Alias (orion, perseus, hercules) without entering a password.
This is a bit tedious for users to type, so it is a prime candidate
for encapsulating in a shell script.

effettivamente si possono dare dei diritti specificando dei
parametri. Come era venuto in mente a me ... parla
anche di mettere il comando in uno script. Ovvio se
e' cosi' specifico ... che senso ha digitarlo ogni volta.

Pero' diversamente da quello che pensavo io,
invece di creare uno script e dare a quello i diritti
di sudo, conviene darli direttamente al comando
utilizzato e semmai usare uno script come promemoria.

Credo comunque che ci possano essere anche dei casi limite ...
... supponiamo di voler definire che il mount puo'
essere fatto soltanto durante gli orari di ufficio ...
... per questi ci vuole uno script apposito.

Per esempio mi viene in mente pmount ... usato in gnome-mount

Davide wrote:

ALL CDROM = NOPASSWD: /sbin/umount /CDROM,\
               /sbin/mount -o nosuid\,nodev /dev/cd0a /CDROM

This is a bit tedious for users to type, so it is a prime candidate
for encapsulating in a shell script.

<nitpicking>
Questo caso specifico e' un prime candidate per essere inserito in
/etc/fstab. :wink:
</nitpicking>

Nel caso generale, quando il comando diventa piu' complesso, ti do ragione.

Thomas

Effettivamente anch'io concordo che quel tipo di comado
andrebbe piuttosto in fstab che in sudo.

A proposito di mount e quel comando. Se non ho capito
male il nosuid serve per evitare che uno monti un
dispositivo esterno su cui magari preventivamente
a casa o su un'altro computer e' riuscito a creare
un comando dando il bit di suid e quindi di poterlo
lanciare magari come root. Ho indovinato?

Ma il nodev? Che pericoli ha?

2009/6/10 Thomas Pircher <tehpeh(a)gmx.net>

Davide wrote:

Se non ho capito
male il nosuid serve per evitare che uno monti un
dispositivo esterno su cui magari preventivamente
a casa o su un'altro computer e' riuscito a creare
un comando dando il bit di suid e quindi di poterlo
lanciare magari come root. Ho indovinato?

Si'. :slight_smile:

Ma il nodev? Che pericoli ha?

Il nodev evita che qualcuno a casa si crei un device file (e.g. per il HD
principale) con permessi di accesso per se stesso. Cosi' riuscirebbe a
bypassare i security checks del sistema.

In ogni caso, queste misure non ti danno sicurezza assoluta perche' chi ha
accesso fisico ad una macchina Linux e' praticamente root: (quasi) niente
ti vieta di fare il boot da CDROM, montare il HD e cancellare la root
password. Oppure aggiungere l'opzione "init=/bin/sh" al kernel da LILO o
Grub oppure di staccare il HD e metterlo nel proprio computer, oppure di
drogare il sysadmin per farti dire la password, oppure...

Thomas

Si anch'io concordo con il fatto che se uno
ha accesso fisico alla macchina ... diventare
root e' un gioco da ragazzi (cdrom, chiavetta usb,
ecc...)

Per questo secondo me, se uno ha informazioni
riservate, meglio usare encfs o truecrypt piuttosto
che fare chissa' che cosa con i diritti.

Davide schrieb:

Si anch'io concordo con il fatto che se uno
ha accesso fisico alla macchina ... diventare
root e' un gioco da ragazzi (cdrom, chiavetta usb,
ecc...)

Per questo secondo me, se uno ha informazioni
riservate, meglio usare encfs o truecrypt piuttosto
che fare chissa' che cosa con i diritti.

Io ho cryptato tutto il disco all'installazione di Ubuntu, usando
l'alternate installer.

Con questo non basta una live CD per crackare la password.

Ovvio che se dovessi dare accesso al sistema ad un utente, gli dovrei
dire la passphrase, altrimenti non sarebbe in grado di far partire il
computer. Ma essendo il mio laptop, nessuno tranne me stesso lo deve
avviare...

Su un sistema condiviso userei la cryptazione di singole partizioni
dati. Ma ci sono tantissimi use case diversi e perciò non credo esista
la soluzione ideale per ogni situazione. Dipende molto da quante persone
devono avere accesso al sistema e in questo agli stessi dati.

Patrick