Newsgroup: it.comp.os.linux.sys
Titolo: limitare i comandi disponibili sulla shell

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 :)

Casper wrote:

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.

> 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.
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? :)

 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"?

 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' :))

 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?

Casper wrote:

Ma questo e' vero anche se tu non limiti l'utente "pippo", mi pare.

antani wrote:

Intendo: e' vero anche se non limiti i comandi che l'utente "pippo" puo' 
eseguire (sempre presumendo che pippo sia un utente non root).

> 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).

 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.

 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.

 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.

 seghe mentali , demenza o genialita' :))
useradd -s /bin/su pippo


Bravo! Bello! E' _esattamente_ La Risposta alla domanda.
Problemi? Nel senso e` possibile crackare questo ambiente?
Andrea

gt 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).


Facebook: Massimo Bacilieri


ï¿œ 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.


 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

 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.

 
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ï¿œ

 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.

 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.

 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.


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).


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

 può diventare chiunque altro conoscendo solo la propria password.
No, dipende da come configuri sudoers.

twistedbrain wrote:

Ok, adesso ho capito cosa intendi. Continuo a ritenerla una limitazione 
superflua, ma naturalmente ognuno ha un diverso grado di paranoia :)

 No, dipende da come configuri sudoers.
Ovvero, come lo configuri?

 l'esecuzione del comando diretto.
O meglio, regoli ciò che può essere eseguito con sudo.

 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.

 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 -.

 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

 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.

 ï¿œ 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.

 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.


 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

 login con password di 20 caratteri di ordinalita'.
thank you all :)

 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


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

 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
