Eliminare la richiesta della password per utente limitato

[kiroken]

Ciao ho creato un utente limitato (ha i privilegi minimi solo quello di modificare la sua home) e mi chiedevo se ai fini della sicurezza, dato che questo utente dovrebbe essere utilizzabile da chiunque, se potevo eliminare in tutta tranquillità la password per il login oppure se questo poteva creare qualche problema (e se posso come si fa ). Volevo inoltre impedirgli di poter ottenere i permessi di root attraverso gksu & company.

grazie

[HomerCube]

Eliminare la richiesta della password è semplice, vedi ad esempio qui, ma non è una buona idea. Il fatto che lasci una porta di casa aperta non può tranquillizzarti se credi che sia troppo piccola perché ci passi un ladro, perché un domani potrebbe entrarvi magari un serpente a sonagli (spero che si colga il senso della metafora...).

[kiroken]

si ma pensavo in quanto l'utente ha comunque privilegi limitati non poteva essere sfruttato (non temo attacchi fisici al pc mi preoccupo solo di quelli dall'esterno) e in ogni caso sarei comunque sempre loggato con un utente quando uso debian e tra tutti quelli del mio sistema questo è il più debole in che modo potrebbe essere sfruttato per un attacco?

[HomerCube]

Io non sono un esperto di sicurezza, ma qualche idea mi viene. Ad esempio, potrebbe il tuo utente lanciare un comando ps -ef o netstat -na? Se sì. un aggressore potrebbe identificare i processi in esecuzione e/o le porte in ascolto, informazioni assai preziose per lui
Chi ha accesso al sistema vede in maniera trasparente files come /etc/passwd, ed anche questo non è il massimo, se non altro perché da lì associ le utenze ai loro UID, e quindi di seguito ai loro processi.
Inoltre, a meno di effettuare pesanti configurazioni sui privilegi globali o impiegare le ACL, anche un utente "debole" potrebbe sovrascrivere contenuti in /tmp (od in altri percorsi a basso rischio), il che in genere ha poco peso, ma se riesce così a sfruttare un bug di qualche programma che vi appoggia degli eseguibili per il proprio funzionamento, potrebbe indurre il sistema a svolgere azioni non previste.

Una regola di base, forse non la prima ma certo non l'ultima, della sicurezza, è: non dare ai tuoi avversari dei vantaggi non richiesti. I crackers sono già abbastanza in gamba da sfondare barriere ben costruite, figuriamoci ingressi spalancati... IMHO

[kiroken]

grazie per la risposta ma quello che volevo dire è che se io sul mio sistema ho ammettiamo gli utenti pippo e pluto.
- pippo: utente limitato a cui voglio concedere di poter usare gksu per questa particolarità questo utente ha una password non banale.
- pluto: utente limitato a cui voglio togliere la possibilità di poter usare gksu ed eliminare la richiesta della password.

Ora se io sono loggato con pluto il problema password non dovrebbe porsi perchè comunque qualunque processo che viene creato appartiene a lui. Se sono loggato con pippo i processi che vengono creati hanno comunque privilegi simili a quelli di pluto (escludendo la diversa home) quindi perchè un eventuale programma malevolo dovrebbe voler ottenere quelli di pluto? potrebbe volerli per infettare anche quell'utente ma per me è molto più grave se ad infettarsi è pippo, pluto è un utente di scarsa importanza non ho nessun problema a cancellare l'utente se infettato e ricrearlo (non ci sono particolari configurazioni nei programmi (o meglio nulla di troppo lungo da riconfigurare) o dati importanti). A me interessava il fatto di impedire che se pluto è infettato possa infettare pippo ma non vedo come l'introdurre la password o meno possa influire mi sfugge qualcosa?

[HomerCube]

Come ho detto, non sono un esperto di sicurezza, quindi le mie osservazioni hanno un carattere generico. Da profano, non me la sento di dire che ammettere libero accesso ad un utente è plausibile in un contesto in cui esso non può fare danni, perché non ho un orizzonte sufficientemente ampio del concetto di "fare danni".
Una cosa che ho colpevolmente omesso di sottolineare in precedenza, invece, è il prendere in considerazione una soluzione alternativa e, soprattutto, standard: ricorrere a SSL con uso delle chiavi. Puoi facilmente generare la canonica coppia di chiavi asimmetriche e consegnare la pubblica alla macchina che dovrà accedere al sistema. Questo non scongiurerà i poteri del tuo utente, ma almeno limiterà ai soli necessari i sistemi che dovranno poter avvalersene. GIYF: la Rete è ricca di documentazione sull'argomento, ma puoi tranquillamente cominciare da qua.

[le0n]

per avere un utente senza password vedi le man di useradd e adduser, altrimenti (come detto) basta togliere la parte relativa alla password in /etc/shadow...

per impedire l'uso di gksu al momento mi viene in mente solo una cosa: gksu ha questi permessi

Codice:

-rwxr-xr-x 1 root root 24696 23 nov 11:46 /usr/bin/gksu

postresti farlo diventare tipo

Codice:

-rwxr-x--- 1 root pippo 24696 23 nov 11:46 /usr/bin/gksu

(con un chmod 750) in cui il gruppo pippo ha la possibilità di eseguire gksu mentre tutti gli altri non appartenenti al gruppo (e non root) non possono avviarlo, stesso dicasi per tutti i file/programmi "a rischio" indicati da HomerCube...
unico accorgimento è di controllare dopo gli upgrade, perché se ad esempio si dovesse aggiornare gksu non so se i permessi tornino ad essere quelli originali ...

il tutto implica che tu ti fidi di chi si siede davanti a questi pc...

HTH!