$ comando di comando chsh con Set-UID

chsh è setuid perché per cambiare la shell di un utente, è necessario modificare il file% di sola lettura di/etc/passwd di proprietà di root.

L'amministratore di sistema potrebbe voler limitare le shell che un utente può scegliere, ad esempio se agli utenti viene assegnata una shell che registra tutti i comandi su syslog. Il modo tradizionale per farlo sarebbe quello di rimuovere tutte le altre shell dal file /etc/shells , poiché chsh limita gli utenti a scegliere le shell in quel file. (Questo implica che per gli utenti che non sono limitati in questo modo, un amministratore ha bisogno di cambiare le proprie shell manualmente - modificando /etc/passwd - poiché non possono più usare chsh per farlo).

Non esiste alcuna vulnerabilità per un utente normale per cambiare la propria shell.

Tuttavia, la shell di un utente è memorizzata nel database dell'utente, insieme ad altri campi sensibili. La maggior parte delle varianti Unix memorizza il database degli utenti locali in un singolo file, /etc/passwd . (Il nome deriva dal fatto che Unix originale memorizzava le password degli utenti in quel file, mentre nei sistemi moderni le password non sono più memorizzate in /etc/passwd , che è leggibile da un mondo intero, ma in un file che non è leggibile da un mondo intero , ad esempio /etc/shadow su Solaris e Linux.) Sebbene consentire a un utente normale di modificare la shell non è un problema di sicurezza, alcuni altri campi sono sensibili (ad esempio l'ID utente), ma per lo più il file contiene informazioni su tutti gli utenti quindi consentire a un utente di modificarlo sarebbe disastroso in quanto potrebbe cambiare l'account di chiunque altro.

Quindi gli utenti possono modificare solo /etc/passwd indirettamente, tramite comandi come chsh e chfn .

Inoltre, sarebbe una vulnerabilità consentire agli utenti con restrizioni di cambiare le proprie shell. Un account può essere limitato per eseguire un comando specifico impostando quel comando specifico nulla come la loro shell (o persino o efficacemente impedito dal logging del tutto impostando /sbin/nologin o /bin/false - o /bin/true per quella materia - come la shell ). Se l'utente fosse in qualche modo in grado di cambiare la propria shell di login, eliminerebbe la restrizione dell'account. La restrizione è implementata in chsh rifiutando di cambiare la shell se la shell corrente dell'utente non è in una lista bianca di shell "generaliste" consentite memorizzate in /etc/shells .

Inoltre, il comando chsh rifiuta di cambiare la shell di a di un utente che non è in questa lista bianca. Ciò garantisce che gli utenti non si blocchino dal proprio account impostando una shell non valida, il che non rappresenta un problema di sicurezza, ma è un problema di supporto.

Per riassumere, chsh deve avere privilegi elevati perché è necessario modificare un file condiviso tra tutti gli utenti. Ciò consente a chsh di applicare ulteriori politiche utili.

Anche se sarebbe possibile suddividere la shell in un file per utente separato, sarebbe necessario un design più complesso con un file separato per account. Unix era basato su disegni semplici, con informazioni memorizzate su un file di testo piatto. Il controllo dell'accesso a grana fine con un dato per file non è tradizionale, avrebbe un impatto sulle prestazioni (non molto grande al giorno d'oggi) e i vantaggi in termini di sicurezza (non richiede chsh e chfn per avere privilegi elevati) sono piuttosto piccoli Quindi non ci sono motivi validi per cambiare questo design.

Mentre sarebbe possibile e relativamente semplice rendere /etc/passwd di proprietà di un account di sistema dedicato (o meglio di un gruppo) e rendere chsh setuid (o meglio, setgid) a quell'account dedicato, non ci sarebbe è davvero un vantaggio per la sicurezza. Se riesci a sfruttare chsh , non importa cos'altro puoi fare con chsh stesso, ti sarà praticamente garantito il permesso di accedere all'account root.