limitare i comandi disponibili sulla shell
Casper
sto cercando di capire come fare per limitare i comandi disponibili
sulla shell di uno specifico utente.
In pratica, vorrei che quando questo utente si è loggato tramite SSH,
abbia la possibilità di lanciare un solo specifico comando ("su -
ALTRO_UTENTE").
Ho visto che con sshd si può specificare un "command" però non ho
capito bene se può fare al caso mio.
Ho visto anche che ci sono shell come "limited shell", però vorrei
evitare di usare diciamo così pacchetti esterni.
Esiste già qualcosa con gli strumeti bash e opensshd ?
Grazie :)
antani
bash -r ti fa partire una restricted shell, senza bisogno di niente di
esterno. Se questo poi sia adeguato a quello che vuoi fare tu (che e'
alquanto vago e fumoso dalla tua descrizione, e traspare il fatto che
probabilmente ci sono modi piu' lineari di farlo), non saprei dire.
Casper
grazie, ho guardato la "restricted shell" però diciamo che fa fare
troppo :)
quello che vorrei fare io è questo:
Devo abilitare l'accesso al mio pc da remoto, tramite ssh, e solo per
uno specifico utente "pippo".
Quando "pippo" è entrato, l'unica cosa che deve poter fare è "su -
altroutente".
Perchè questo?
Perchè voglio limitare l'accesso dall'esterno a uno user specifico,
dato che "altroutente" ha i privilegi di administrator.
D'altro canto avendo necessità di usare "altroutente", una volta
entrato come "pippo" devo poter fare "su -" , ma soltanto questo.
Forse l'idea è alquanto bizzarra? :)
antani
>> bash -r ti fa partire una restricted shell
>
>
> grazie, ho guardato la "restricted shell" però diciamo che fa fare
> troppo :)
> quello che vorrei fare io è questo:
> Devo abilitare l'accesso al mio pc da remoto, tramite ssh, e solo per
> uno specifico utente "pippo".
> Quando "pippo" è entrato, l'unica cosa che deve poter fare è "su -
> altroutente".
>
> Perchè questo?
> Perchè voglio limitare l'accesso dall'esterno a uno user specifico,
> dato che "altroutente" ha i privilegi di administrator.
Scusa eh, ma se "pippo" puo' diventare administrator (o root), che senso ha
limitare quello che puo' fare come "pippo"?
Casper
> Scusa eh, ma se "pippo" puo' diventare administrator (o
> root), che senso ha
> limitare quello che puo' fare come "pippo"?
questo doppio pasaggio servirebbe solo a costringere la conoscenza di
2 password per avere il controllo completo del sistema.
se non hai la pwd / chiave privata di pippo, non entri, e pure ammesso
che riesci a entrare con pippo, devi conoscere un'altra pwd per fare
qualcosa di utile
seghe mentali , demenza o genialita' :))
Giuseppe Della Bianca
> ciao,
>
> sto cercando di capire come fare per limitare i comandi disponibili
> sulla shell di uno specifico utente.
>
> In pratica, vorrei che quando questo utente si è loggato tramite SSH,
]zac[
Forse abilitando e settando su tutti i comandi gli attributi estesi?
Forse usando selinux, apprmor e altri sistemi simili?
antani
Ma questo e' vero anche se tu non limiti l'utente "pippo", mi pare.
antani
Intendo: e' vero anche se non limiti i comandi che l'utente "pippo" puo'
eseguire (sempre presumendo che pippo sia un utente non root).
Giuseppe Della Bianca
> Casper wrote:
>
>> ciao,
>>
>> sto cercando di capire come fare per limitare i comandi disponibili
>> sulla shell di uno specifico utente.
]zac[
Altra possibilità, usare chroot (creando una '''scatola chiusa''' con quello
che gli serve), impostare diversamente i permessi del proprietario e del
gruppo e il gruppo di tutto i comandi (sconsigliato, probabili effetti
collaterali non prevedibili).
Giuseppe Della Bianca
]zac[
> se non hai la pwd / chiave privata di pippo, non entri, e pure ammesso
> che riesci a entrare con pippo, devi conoscere un'altra pwd per fare
> qualcosa di utile
>
> seghe mentali , demenza o genialita' :))
A volte è utile consentire ad un utente non privilegiato la possibilità di
passare ad amministratore, senza dargli la password di root (dare ad altri
la password di root, per esempio via e-mail, non è una buona idea), per
esempio per una amministrazione condivisa.
Perché poi basta disabilitare l'utente non privilegiato per bloccare l'altro
accesso di '''co-amministratore'''.
Naturalmente questo esige che ci sia una buona fiducia verso
l'altro '''amministratore''', e sapere che comunque chi è amministratore
potenzialmente può fare quello vuole, per esempio installare rootkit,
copiarsi le password criptate e usare tool di cracking, ecc. .
A naso chi ha iniziato questo thread ha questa esigenza e in più non si fida
dell'amministratore aggiunto.
Giuseppe Della Bianca
]zac[
> Intendo: e' vero anche se non limiti i comandi che l'utente "pippo" puo'
> eseguire (sempre presumendo che pippo sia un utente non root).
Il fatto è che impossibile prevedere tutte i possibili modi e comandi che
possano essere usati per aggirare le limitazioni imposte ad un utente che
essendo root è praticamente il padrone della macchina.
Basta anche un solo programma che abbia una minima possibilità di essere
usato o manovrato, che abbia un bug, una funzione pensata per altri scopi
ma che usata con fantasia sia possibile usare per altri scopi ... e zac ...
in un instante si riacquista il controllo completo.
In sintesi le probabilità di successo della limitazione di un utente
amministratore ostile, sono prossimo al sottozero (se non è ostile non ha
senso limitarlo).
Piuttosto valuta strade alternative, chroot, sistemi virtuali, ecc.,
qualsiasi cosa che poi verrà distrutta completamente.
antani
> antani wrote:
>
> ]zac[
>> Intendo: e' vero anche se non limiti i comandi che l'utente "pippo" puo'
>> eseguire (sempre presumendo che pippo sia un utente non root).
>
> Il fatto è che impossibile prevedere tutte i possibili modi e comandi che
> possano essere usati per aggirare le limitazioni imposte ad un utente che
> essendo root è praticamente il padrone della macchina.
Sono d'accordo.
> Basta anche un solo programma che abbia una minima possibilità di essere
> usato o manovrato, che abbia un bug, una funzione pensata per altri scopi
> ma che usata con fantasia sia possibile usare per altri scopi ... e zac
> ... in un instante si riacquista il controllo completo.
Vero.
> In sintesi le probabilità di successo della limitazione di un utente
> amministratore ostile, sono prossimo al sottozero (se non è ostile non ha
> senso limitarlo).
>
>
> Piuttosto valuta strade alternative, chroot, sistemi virtuali, ecc.,
> qualsiasi cosa che poi verrà distrutta completamente.
Sono d'accordo su tutto. Io stavo semplicemente constatando che avere un
utente limitato quanto vuoi, che pero' puo' eseguire "su -
utenteprivilegiato" (questa era la richiesta dell'OP) non mi pare aggiunga
nessuna protezione. Tanto vale lasciare i privilegi di default, che comunque
sono di non-root.
gt
> questo doppio pasaggio servirebbe solo a costringere la conoscenza di
> 2 password per avere il controllo completo del sistema.
>
> se non hai la pwd / chiave privata di pippo, non entri, e pure ammesso
> che riesci a entrare con pippo, devi conoscere un'altra pwd per fare
> qualcosa di utile
>
> seghe mentali , demenza o genialita' :))
useradd -s /bin/su pippo
twistedbrain
Bravo! Bello! E' _esattamente_ La Risposta alla domanda.
Problemi? Nel senso e` possibile crackare questo ambiente?
Andrea
antani
Piuttosto che quello allora (che non so nemmeno se funziona) sarebbe meglio
usare sudo e mettere pippo in /etc/sudoers in modo che possa solo eseguire
il comando "su" (anche se, ripeto, mi pare una limitazione superflua visto
che comunque puo' diventare root).
Crononauta
>> useradd -s /bin/su pippo
>
> Bravo! Bello! E' _esattamente_ La Risposta alla domanda.
> Problemi? Nel senso e` possibile crackare questo ambiente?
A me sembra tutto un segone mentale fuori misura: se l'utente pippo ￜ un
utente non privilegiato, potrￜ girare nella sua home e fare ben poco altro.
E una volta che passa a root, farￜ quello che vuole.
Quindi non c'ￜ motivo di preoccuparsi di cosa puￜ fare pippo come utente di
per sￜ, login interattivo o no.
Equivale, nￜ piￜ nￜ meno, ad impedire il login via ssh per root: io
usualmente la prima cosa che faccio ￜ quella di creare un gruppo "sshusers"
cui iscrivo gli utenti che voglio abilitare all'accesso ssh, e poi permetto
il login solo a questo gruppo.
--
Massimo Bacilieri AKA Crononauta
Skype: crononauta <massimo....@gmail.com>
Facebook: Massimo Bacilieri
Crononauta
ￜ il comportamento di default quando sshd non permette l'accesso diretto di
root (basta imporre il parametro "PermitRootLogin" a no), quindi non vedo il
motivo di fare tanti giri acrobatici.
twistedbrain
> On Sun, 15 Nov 2009 12:44:06 -0800 (PST), twistedbrain <andrea.ferra...@gmail.com> wrote:
> >> useradd -s /bin/su pippo
>
> > Bravo! Bello! E' _esattamente_ La Risposta alla domanda.
> > Problemi? Nel senso e` possibile crackare questo ambiente?
>
> utente non privilegiato, potrà girare nella sua home e fare ben poco altro.
Questo non e` vero; ci sono exploit non attuabili da remoto, che pero`
possono essere attuati da utenti con account locale normale con una
shell normale (e/o restricted).
> E una volta che passa a root, farà quello che vuole.
Certo, ma il problema da cui ci si vuole garantire non e` questo, e`
che chi non e` autorizzato a collegarsi comprometta il sistema e
imporre la conoscenza di un nome utente e una password, oltre a quella
di root diminuisce questo rischio, soprattutto se l'utente locale non
ha shell, ma solo la possibilita` di fornire un'altra password per
diventare root. Insomma impone che per diventare root da remoto tu
conosca due password e un utente e che solo con la prima password tu
non possa fare assolutamente nulla.
Se invece la questione fosse di limitare le azioni da eseguire come
root e` chiaro che la strada non sarebbe questa, ma sudo.
> Quindi non c'è motivo di preoccuparsi di cosa può fare pippo come utente di
> per sé, login interattivo o no.
Come ti scrivevo si`, perche' ci sono exploit locali che senza accesso
al sistema e una shell non sono attuabili.
Andrea
gt
> Piuttosto che quello allora (che non so nemmeno se funziona) sarebbe
> meglio usare sudo e mettere pippo in /etc/sudoers in modo che possa solo
> eseguire il comando "su" (anche se, ripeto, mi pare una limitazione
> superflua visto che comunque puo' diventare root).
per funzionare funziona.
con sudo concedi a pippo la possibilit� di eseguire comandi come root (o
altro utente), non limiti la possibilit� di eseguire quelli che pu� eseguire
come utente non privilegiato. o no?
se dai a pippo la possibilit� di eseguire su con sudo, quindi con i
privilegi di root, pu� diventare qualsiasi altro utente senza conoscerne la
password.
gt
> ￜ il comportamento di default quando sshd non permette l'accesso diretto
> di root (basta imporre il parametro "PermitRootLogin" a no), quindi non
> vedo il motivo di fare tanti giri acrobatici.
>
paranoie di sicurezza.
se pippo ￜ l'unico utente che puￜ fare login da remoto, se non puￜ fare
altro che autenticarsi per diventare root questo gli impedisce di copiarsi
file, scrivere in /tmp, riempire la partizione /home, etc.
ￜ un qualcosa in piￜ
antani
> antani wrote:
>
>
>> Piuttosto che quello allora (che non so nemmeno se funziona) sarebbe
>> meglio usare sudo e mettere pippo in /etc/sudoers in modo che possa solo
>> eseguire il comando "su" (anche se, ripeto, mi pare una limitazione
>> superflua visto che comunque puo' diventare root).
>
>
> per funzionare funziona.
> con sudo concedi a pippo la possibilità di eseguire comandi come root (o
> altro utente), non limiti la possibilità di eseguire quelli che può
> eseguire come utente non privilegiato. o no?
Esatto. La seconda limitazione la considero superflua, visto che puo'
diventare root e cambiare le cose come e quando gli pare.
> se dai a pippo la possibilità di eseguire su con sudo, quindi con i
> privilegi di root, può diventare qualsiasi altro utente senza conoscerne
> la password.
Siccome puo' diventare root, quella e' solo *una* delle mille cose che puo'
fare, e limitarlo ad usare solo "su" non credo aiuti a prevenirlo.
antani
>> Quindi non c'è motivo di preoccuparsi di cosa può fare pippo come utente
>> di per sé, login interattivo o no.
>
> Come ti scrivevo si`, perche' ci sono exploit locali che senza accesso
> al sistema e una shell non sono attuabili.
Quell'utente in definitiva acquisira' i privilegi di un altro utente, il
quale secondo utente avra' si' una shell. Quindi forse il primo utente non
potra' fare nulla, ma tutti gli exploit di cui parli potra' (se vuole)
tranquillamente eseguirli una volta acquisiti i privilegi del secondo
utente.
gt
> gt wrote:
> > con sudo concedi a pippo la possibilità di eseguire comandi come root (o
> > altro utente), non limiti la possibilità di eseguire quelli che può
> > eseguire come utente non privilegiato. o no?
>
> Esatto. La seconda limitazione la considero superflua, visto che puo'
> diventare root e cambiare le cose come e quando gli pare.
Qualunque utente di default può diventare root se sa la password, non
occorre metterlo in sudoers.
> > se dai a pippo la possibilità di eseguire su con sudo, quindi con i
> > privilegi di root, può diventare qualsiasi altro utente senza conoscerne
> > la password.
>
> Siccome puo' diventare root, quella e' solo *una* delle mille cose che puo'
> fare, e limitarlo ad usare solo "su" non credo aiuti a prevenirlo.
Può diventare root solo se conosce la password. Mettendolo in sudoers
può diventare chiunque altro conoscendo solo la propria password.
twistedbrain
Certamente si`, ma per farlo dovra` conoscere 2 password e almeno un
nome utente.
Ripeto questo non e` fatto per evitare che chi ha diritto di accedere
possa cercare di fare cose illecite, ma per evitare che chi non ha
diritto di accedere lo faccia e in questo secondo caso e in questo
scenario (mettendo come shell al primo utente su) per riuscirci non
gli basterebbe aver bucato il primo account (username e password), ma
dovrebbe averne bucati 2 (2a password).
twistedbrain
Comunque probabilmente e` possibile mettere insieme le due cose, nel
senso
che metti come shell al primo utente "su - semiadmin" e limiti i
comandi eseguibili
come root semiadmin con sudo solo a quelli che gli sono necessari.
Andrea
antani
> On 15 Nov, 22:28, antani <ant...@mail.not> wrote:
>> gt wrote:
>
>> > con sudo concedi a pippo la possibilità di eseguire comandi come root
>> > (o altro utente), non limiti la possibilità di eseguire quelli che può
>> > eseguire come utente non privilegiato. o no?
>>
>> Esatto. La seconda limitazione la considero superflua, visto che puo'
>> diventare root e cambiare le cose come e quando gli pare.
>
>
> Qualunque utente di default può diventare root se sa la password, non
> occorre metterlo in sudoers.
Eh no. Puoi implementare una policy (tramite sudo) per cui solo certi utenti
possono diventare root. Ed esempio una cosa che si fa e' permettere solo
agli utenti che sono nel gruppo "wheel" di diventare root.
>> > se dai a pippo la possibilità di eseguire su con sudo, quindi con i
>> > privilegi di root, può diventare qualsiasi altro utente senza
>> > conoscerne la password.
>>
>> Siccome puo' diventare root, quella e' solo *una* delle mille cose che
>> puo' fare, e limitarlo ad usare solo "su" non credo aiuti a prevenirlo.
>
>
> Può diventare root solo se conosce la password. Mettendolo in sudoers
> può diventare chiunque altro conoscendo solo la propria password.
No, dipende da come configuri sudoers.
antani
Ok, adesso ho capito cosa intendi. Continuo a ritenerla una limitazione
superflua, ma naturalmente ognuno ha un diverso grado di paranoia :)
gt
> gt wrote:
> > Qualunque utente di default può diventare root se sa la password, non
> > occorre metterlo in sudoers.
>
> Eh no. Puoi implementare una policy (tramite sudo) per cui solo certi utenti
> possono diventare root. Ed esempio una cosa che si fa e' permettere solo
> agli utenti che sono nel gruppo "wheel" di diventare root.
Ho detto "di default", poi puoi implementare tutte le policy che
vuoi.
Comunque non lo fai tramite sudo, piuttosto tramite un cambio di
permessi sull'eseguibile.
Con sudoers limiti quello che può essere eseguito con sudo, non limiti
l'esecuzione del comando diretto.
> > Può diventare root solo se conosce la password. Mettendolo in sudoers
> > può diventare chiunque altro conoscendo solo la propria password.
>
> No, dipende da come configuri sudoers.
Ovvero, come lo configuri?
gt
> Con sudoers limiti quello che può essere eseguito con sudo, non limiti
> l'esecuzione del comando diretto.
O meglio, regoli ciò che può essere eseguito con sudo.
antani
> On 15 Nov, 22:43, antani <ant...@mail.not> wrote:
>> gt wrote:
>
>> > Qualunque utente di default può diventare root se sa la password, non
>> > occorre metterlo in sudoers.
>>
>> Eh no. Puoi implementare una policy (tramite sudo) per cui solo certi
>> utenti possono diventare root. Ed esempio una cosa che si fa e'
>> permettere solo agli utenti che sono nel gruppo "wheel" di diventare
>> root.
>
>
> Ho detto "di default", poi puoi implementare tutte le policy che
> vuoi.
> Comunque non lo fai tramite sudo, piuttosto tramite un cambio di
> permessi sull'eseguibile.
No, lo fai (generalmente) con PAM. Non c'e' bisogno di cambiare i permessi
di nulla (per fortuna).
> Con sudoers limiti quello che può essere eseguito con sudo, non limiti
> l'esecuzione del comando diretto.
Limiti l'esecuzione del comando /come root/. E' questo che intendevo, sorry
se non mi sono spiegato bene.
>> > Può diventare root solo se conosce la password. Mettendolo in sudoers
>> > può diventare chiunque altro conoscendo solo la propria password.
>>
>> No, dipende da come configuri sudoers.
>
> Ovvero, come lo configuri?
Per esempio, puoi configurare sudoers in modo che chieda la password di root
anziche' quella dell'utente (vedi rootpw). Oppure puoi (come detto) usare il
gruppo wheel (o un altro gruppo) per fare si' che solo certi gruppi di
utenti possano eseguire sudo con certi comandi. Quindi un utente "normale",
non appartenente a nessuno di quei gruppi, sapendo solo la sua password non
puo' fare nulla di particolare.
gt
> Per esempio, puoi configurare sudoers in modo che chieda la password di root
> anziche' quella dell'utente (vedi rootpw). Oppure puoi (come detto) usare il
> gruppo wheel (o un altro gruppo) per fare si' che solo certi gruppi di
> utenti possano eseguire sudo con certi comandi. Quindi un utente "normale",
> non appartenente a nessuno di quei gruppi, sapendo solo la sua password non
> puo' fare nulla di particolare.
Ricapitolando:
metti pippo in wheel e configuri sudoers in modo che il gruppo wheel
possa eseguire su con i privilegi di root fornendo la password di
root.
Non impedisci a pippo di eseguire un semplice su - (non con sudo, al
limite lo fai con pam)
Non impedisci a pippo di eseguire qualsiasi altro comando disponibile
ad un utente non privilegiato.
A che scopo?
Casper voleva che pippo, l'unico utente al quale è permesso fare login
tramite ssh, potesse eseguire soltanto su -.
Casper
> che chi non e` autorizzato a collegarsi comprometta il sistema e
> imporre la conoscenza di un nome utente e una password, oltre a quella
> di root diminuisce questo rischio, soprattutto se l'utente locale non
> ha shell, ma solo la possibilita` di fornire un'altra password per
> diventare root. Insomma impone che per diventare root da remoto tu
> conosca due password e un utente e che solo con la prima password tu
> non possa fare assolutamente nulla.
esattamente questo e, il mio scopo :)
intanto mi avete suggerito varie belle cosette, dal useradd, al
selinux/apparmor (il quale forse e' troppo per quel che mi serve) al
sudoers (che pero' penso sia non applicabile, forse ho capito male)
grazie perche' il tempo di vedere un film, e sono tornato qui piu'
istruito di prima con tutti questi reply un piacere davvero :)
faccio dei tentativi con i vostri suggerimenti, ma mi fa piacere
parlare dello scenario anche per apire come gestireste voi la cosa :)
grazie e ciao per ora
antani
> On 15 Nov, 23:00, antani <ant...@mail.not> wrote:
>
>> Per esempio, puoi configurare sudoers in modo che chieda la password di
>> root anziche' quella dell'utente (vedi rootpw). Oppure puoi (come detto)
>> usare il gruppo wheel (o un altro gruppo) per fare si' che solo certi
>> gruppi di utenti possano eseguire sudo con certi comandi. Quindi un
>> utente "normale", non appartenente a nessuno di quei gruppi, sapendo solo
>> la sua password non puo' fare nulla di particolare.
>
>
> Ricapitolando:
> metti pippo in wheel e configuri sudoers in modo che il gruppo wheel
> possa eseguire su con i privilegi di root fornendo la password di
> root.
> Non impedisci a pippo di eseguire un semplice su - (non con sudo, al
> limite lo fai con pam)
Certo che puo' digitarlo dalla shell, ma se non sa la password non va molto
lontano (e il tentativo fallito viene comunque loggato).
> Non impedisci a pippo di eseguire qualsiasi altro comando disponibile
> ad un utente non privilegiato.
> A che scopo?
> Casper voleva che pippo, l'unico utente al quale è permesso fare login
> tramite ssh, potesse eseguire soltanto su -.
Ecco, e' quello che io non capivo. Se puo' fare "su -", allora una volta
root puo' anche cambiare le cose in modo da eliminare quella (artificale)
limitazione.
Ma le mie ultime risposte non riguardavano specificamente quello, erano solo
risposte alle tue domande.
Crononauta
> paranoie di sicurezza.
> se pippo ￜ l'unico utente che puￜ fare login da remoto, se non puￜ fare
> altro che autenticarsi per diventare root questo gli impedisce di copiarsi
> file, scrivere in /tmp, riempire la partizione /home, etc.
Sai cosa gliene frega, visto che ha la password di root...
gt
> On Sun, 15 Nov 2009 22:21:05 +0100, gt <g.t...@lycos.it> wrote:
>> paranoie di sicurezza.
>> se pippo ￜ l'unico utente che puￜ fare login da remoto, se non puￜ fare
>> altro che autenticarsi per diventare root questo gli impedisce di
>> copiarsi file, scrivere in /tmp, riempire la partizione /home, etc.
>> ￜ un qualcosa in piￜ.
>
> Sai cosa gliene frega, visto che ha la password di root...
>
parti dal presupposto che sia qualcuno che ha scoperto la password di pippo
ma che non sia il vero pippo.
forse non ha la password di root.
Crononauta
> parti dal presupposto che sia qualcuno che ha scoperto la password di pippo
> ma che non sia il vero pippo.
> forse non ha la password di root.
In quel caso dovrebbe solo contare su degli exploit, ma a questo punto se
parliamo di exploit teorici (non che in passato non ce ne siano stati al
riguardo, eh, ma non ￜ che ne trovino uno al giorno), allora dovremmo
considerare anche quelli possibili sullo stesso demone sshd senza la
necessitￜ di un login, e allora ciao...
Poi sￜ, piￜ banalmente il falso pippo potrebbe mettere uno sniffer in pippo
e scoprire la password di root quando il vero pippo si collega... questo
sarebbe effettivamente l'unico punto di vantaggio del non dare una shell.
Roberto C
> ciao,
> sto cercando di capire come fare per limitare i comandi disponibili
> sulla shell di uno specifico utente.
> In pratica, vorrei che quando questo utente si � loggato tramite SSH,
> abbia la possibilit� di lanciare un solo specifico comando ("su -
> ALTRO_UTENTE").
> Ho visto che con sshd si pu� specificare un "command" per� non ho
> capito bene se pu� fare al caso mio.
> Ho visto anche che ci sono shell come "limited shell", per� vorrei
> evitare di usare diciamo cos� pacchetti esterni.
> Esiste gi� qualcosa con gli strumeti bash e opensshd ?
> Grazie :)
Da quello che ho letto in questo troppo lungo thread, ho capito che il
proposito e' avere piu' sicurezza nell' accesso come root in quanto
il primo user non dovrebbe poter fare altro che diventare root giusto?
Secondo me, per quello che ho letto in atricolo e forums di crittografia
e sicurezza, il sistema che si vuole realizzare non e' piu' sicuro di
un sistema che permetta la login a root con password di doppia ordinalita'.
es:
user: pippo
pass: primapassword
user: root
pass: secondapassword
secondo me equivale (anche volendo usare come crittovariabile lo user
pippo)
user: root
pass: 'pippo:primapassword:secondapassword'
Nelle login si definiscono dei canoni di sicurezza e degli attributi per
considerare password adeguate. Sarebbe un controsenso dire che 10 caratteri
di password sono adeguati per un utente e poi contraddirlo dicendo che e'
piu' sicuro fare login con due password di 10 caratteri. Tanto vale fare
login con password di 20 caratteri di ordinalita'.
Ciao.
Roberto.
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
Casper
> Nelle login si definiscono dei canoni di sicurezza e degli attributi per
> considerare password adeguate. Sarebbe un controsenso dire che 10 caratteri
> di password sono adeguati per un utente e poi contraddirlo dicendo che e'
> piu' sicuro fare login con due password di 10 caratteri. Tanto vale fare
> login con password di 20 caratteri di ordinalita'.
thank you all :)
twistedbrain
> Casper ha scritto:
>
> > ciao,
> > sto cercando di capire come fare per limitare i comandi disponibili
> > sulla shell di uno specifico utente.
> > abbia la possibilità di lanciare un solo specifico comando ("su -
> > ALTRO_UTENTE").
> > Ho visto che con sshd si può specificare un "command" però non ho
> > capito bene se può fare al caso mio.
> > Ho visto anche che ci sono shell come "limited shell", però vorrei
> > evitare di usare diciamo così pacchetti esterni.
> > Esiste già qualcosa con gli strumeti bash e opensshd ?
> > Grazie :)
>
> Da quello che ho letto in questo troppo lungo thread, ho capito che il
> proposito e' avere piu' sicurezza nell' accesso come root in quanto
> il primo user non dovrebbe poter fare altro che diventare root giusto?
> Secondo me, per quello che ho letto in atricolo e forums di crittografia
> e sicurezza, il sistema che si vuole realizzare non e' piu' sicuro di
> un sistema che permetta la login a root con password di doppia ordinalita'.
>
> es:
> user: pippo
> pass: primapassword
>
> user: root
> pass: secondapassword
>
> secondo me equivale (anche volendo usare come crittovariabile lo user
> pippo)
>
> user: root
> pass: 'pippo:primapassword:secondapassword'
>
> Nelle login si definiscono dei canoni di sicurezza e degli attributi per
> considerare password adeguate. Sarebbe un controsenso dire che 10 caratteri
> di password sono adeguati per un utente e poi contraddirlo dicendo che e'
> piu' sicuro fare login con due password di 10 caratteri. Tanto vale fare
> login con password di 20 caratteri di ordinalita'.
>
> Ciao.
> Roberto.
Interessante e credo giiusto, ma, a parte il fatto che la password in
questo caso dovrebbe essere di 30 caratteri, nel senso che non ti
basta sapere la password di pippo e quella di root, ma devi sapere
anche che l'utente del caso e` pippo e quindi considerando questo nome
come una terza password quella da digitare diventa veramente lunga,
ecco, a parte questo c'e` poi anche da considerare l'usabilita` di
tali password. Per quanto riguarda questo aspetto, dato che gli errori
di battitura sono proporzionali al numero di caratteri digitati,
aumenteresti la probabilita` di digitare la password errata e quindi
sia gli errori di accesso registrati nei log, sia i tempi di accesso,
perche' ogni volta dovresti ridigitare una password da 30 caratteri
per intero, insomma, il sistema sarebbe, almeno un po' piu`
difficilmente usabile da questo punto di vista.
Inoltre, punto essenziale, con il sistema descritto di login in 2
passi, potresti far si` che il secondo non ti faccia diventare root,
ma un utente con i privilegi per fare solo le cose che e` necessario
che tu possa fare gestiti con sudo e quindi non conosceresti la
password di root (ammesso che ci sia).
Andrea
twistedbrain
Insomma. ho inanellato una certa serie di ca...te. Nel senso che se
tu
obblighi l'utente piripimpola creato appositamente ad usare una
password
di almeno 20 carattteri e gli configuri sudo in modo appropriato
dovresti
ottenere un livello di sicurezza dello stesso tipo di avere un utente
pippoloneX che collegatosi con password almeno di 10 carattteri puo`
solo dare un'altra password almeno di 10 caratteri per diventare
piripimpola. Rimane il piccolo svantaggio della password da 20
rispetto
alle 2 da 10 per gli eventuali errori di digitazione e anche del fatto
che
verosimilmente la password da 20, per essere sicuro di entrare quando
devi te la scriverai da qualche parte e poi la potrai perdere (te la
potranno
fregare), mentre quelle da 10 magari riesci a ricordarle piu`
agevolemente
e/o a conservarle in due posti diversi (lo puoi fare dividendo in
pezzi anche
quella da 20, pero` e` leggermente meno semplice).
Andrea
Roberto C
> es:
> user: pippo
> pass: primapassword
> user: root
> pass: secondapassword
> secondo me equivale (anche volendo usare come crittovariabile lo user
> pippo)
> user: root
> pass: 'pippo:primapassword:secondapassword'
Anche se il thread e' esaurito, aggiungo una precisazione.
Gli aspetti logistici che portano ad usare 2 login separate con 2 passwd
sono stati esposti, la la mia affermazione su riportata ha bisogno
quantomeno di una precisazione (possiamo dire che E' SBAGLIATA!!)
Parlano solo di sicurezza e non di malleabilita' delle password,
il sistema con una login conunica passwo di 20 caratteri e' da considerarsi
MOLTO piu' sicuro di quello con 2 login con 2 passwo di 10 caratteri l'
uno.
se le password possono usare un set di caratteri alfanumerici + simboli di
punteggiatura ASCII (ammettiamo un centinaio di simboli) e ipotizziamo
l' uso di passwords random abbiamo le seguento grandezze:
set-simboli-possibili-in-password = 100
caratteri-per-password = 20
i tentativi che si dovrebbero fare sarebbero 100 esponente 20 (100 pow 20)
per esplorarle tutte, diciamo che un attaccante con media fortuna debba
fare solo meta' di questi tentativi quindi (100 pow 20) / 2 =
5000000000000000000000000000000000000000 tentativi.
se i 20 caratteri di ordinalita' fossero suddivisi in 2 login, l'
attaccante
dovrebbe indovinare solo i primi 10 caratteri e all' attaccere i secondi
10, avrebbe la validazione dei primi 10 quindi i tentativi sono MAX
100 pow 10 per 2 password
immaginando che probabilisticamente indovini mediamente dopo la meta' dei
tentativi, solo 100 pow 10 tentativi quindi
100000000000000000000
comunque tanti, ma solo il doppio che con una password, non ordini di
grandezza.
Se poi le password non sono random, ma mnemoniche molto meno.
Ciao