Caso d'uso tipico per una password di gruppo

Ho controllato più di mezzo secolo di esperienza su Unix e né i miei colleghi né me stesso hanno mai impostato una password su un gruppo ( sge gpasswd). Quale sarebbe un tipico caso d'uso per una password di gruppo o è praticamente solo lì per motivi storici?

Anch'io non ho mai visto questa funzione usata, nemmeno una volta. La maggior parte delle SA non è nemmeno a conoscenza dell'esistenza di questa struttura. Guardando la pagina man per gpasswdc'era questa nota:

Note sulle password di gruppo

  Group passwords are an inherent security problem since more than one 
  person is permitted to know the password. However, groups are a useful 
  tool for permitting co-operation between different users.

Perché esistono

Penso che siano state un'idea naturale nel simulare il modello di password dell'utente, che aveva senso duplicare quel modello di caso anche nei gruppi. Ma in pratica non sono poi così utili per nulla.

L'idea con una password di gruppo è che se fosse necessario ottenere l'accesso a un determinato gruppo (uno di cui non si è elencati come membri), è possibile farlo utilizzando il newgrpcomando ed essere sfidati con una password per ottenere l'accesso a questi gruppi alternativi.

Il grosso problema con loro è che esiste una sola password per ogni gruppo, costringendo così le persone a condividere questa singola password, quando più persone hanno richiesto l'accesso a questo particolare gruppo.

gruppi

La maggior parte degli ambienti in cui mi sono imbattuto in genere ha messo le persone in gruppi secondari, e quindi ha dato a questi gruppi l'accesso ai file sul filesystem, e questo ha soddisfatto praticamente tutto l'uso necessario.

sudo

Con l'avvento di sudoulteriori autorizzazioni potrebbero essere fornite ai gruppi, se necessario, minando ulteriormente eventuali casi d'uso forniti dalle password di gruppo. Se era necessario consentire agli utenti più autorizzazioni, era molto più semplice creare ruoli sudoe quindi consentire solo il nome utente o il gruppo in cui si trovavano, le autorizzazioni per elevare lì le autorizzazioni in modo che potessero eseguire una determinata attività.

ACL

Infine, la possibilità di creare elenchi di controllo di accesso (ACL) ha dato davvero l'ultima flessibilità che il modello di autorizzazioni Utente / Gruppo / Altro non poteva fornire da solo, relegando all'oscurità l'eventuale necessità di password di gruppo.

Ecco un uso pratico delle password di gruppo, che ho implementato per me stesso sul nostro server di lavoro, poiché i registri indicavano che il mio account era stato forzato (o avrebbe potuto essere un attacco di dizionario).
Ho usato ssh-keygene puttygenrispettosamente generare coppie di chiavi da utilizzare dalla mia workstation e dal mio computer di casa. La chiave che uso da casa richiede una password. Ho aggiunto entrambe le chiavi pubbliche a .ssh/authorized_keys, creato un gruppo marionettecon una password e senza membri. Come root ho usato visudoper aggiungere le seguenti righe.

Cmnd_Alias      SUDOING = /bin/bash, /usr/bin/sudo -i
%marionette     ALL=NOPASSWD:SUDOING

Ho disabilitato la password del mio account, nessuno può accedervi in ​​questo modo. Ora accedo solo con le mie chiavi e inserendo il gruppo protetto da password con newgrp marionettemi permette di diventare root usando sudo -i.
Senza l' NOPASSWD:opzione richiederà la password del tuo account utente . Se è disabilitato e questo gruppo non ha NOPASSWD, non sarà possibile sudo -i. Richiederà anche la password del tuo account utente se l'elenco dei comandi non ha /bin/basho qualunque shell stia usando la tua radice di default.

Mentre questo rende il percorso di sudo più lungo, aggiunge un buon livello di sicurezza. Se scegli di creare tutti i tuoi account in questo modo, crea un account locale con password e privilegi sudo, ma nega la sua voce SSH /etc/ssh/sshd_configaggiungendo qualcosa del tipo:

DenyUsers root caan
DenyGroups root daleks

Ciò è necessario per l'accesso locale in caso di reinstallazione e dimenticanza del backup delle chiavi di accesso.

Non ho mai visto un caso d'uso anche per quella password. E questo è circa 20 anni di esperienza * nix.

L'unico caso d'uso che mi viene in mente è di impostarlo su "!" - bloccato, quindi nessuno, non essendo un membro di quel gruppo, può cambiarlo con il newgrpcomando.

Se guardo in / etc / group su SLES o / etc / gshadow su sistemi basati su RedHat questo sembra essere il "tipico" caso d'uso. SLES non si è nemmeno preoccupato di creare un meccanismo ombra per quella password.

Lasciami suggerire un caso d'uso.

Prima di tutto lasciatemi dire che siamo così abituati al termine "utente" che non ci pensiamo nemmeno. Ma "utente" non è in realtà un utente . Ad esempio, a casa abbiamo tre computer: il laptop di mia moglie, il mio laptop e il desktop comune. Quando uso il laptop di mia moglie accedo con il suo account utente. Quando usa il mio laptop accede con il mio account utente. Se qualcuno ha bisogno del desktop, usa un account comune. Vediamo qui che la cosa che il sistema informatico chiama "utente" non è in realtà un utente ma un flusso di lavoro : un insieme di attività.

Ecco la domanda: perché non posso avere più di un'attività - una per ogni lavoro diverso che ho? Io posso. Sul mio computer di lavoro ho creato (sperimentalmente) molti utenti diversi in modo da potermi concentrare sull'attività corrente. Ho inserito tutti questi utenti nello stesso gruppo in modo da poter accedere ai miei file senza alcun problema quale utente sto attualmente utilizzando.

Quindi dove si inserisce gpasswd in questo?

Il comportamento predefinito di Ubuntu è quello di creare un gruppo speciale per ogni utente.

E se decidessimo di pensare a questi gruppi primari come utenti e di pensare agli utenti del sistema come flussi di lavoro ?

Di questi nuovi utenti avrebbe bisogno di una password per accedere, giusto? Ecco il posto di gpasswd. Devo ancora capire come accedere con il gruppo (fino a questo punto quello che so è che puoi cambiare gruppo con gpasswd se hai già effettuato l'accesso).