Progetto

Generale

Profilo

Segnalazione #742

Analisi permessi

Aggiunto da Enrico Zini 2 mesi fa. Aggiornato 20 giorni fa.

Stato:
Nuovo
Priorità:
Normale
Assegnato a:
Versione prevista:
Inizio:
19-02-2019
Scadenza:
% completato:

0%

Resolution:

Descrizione

Documentare chi può fare cosa su fuss-manager

autorizzazioni-octonet.png Mostra (29,9 KB) Paolo Dongilli, 04-03-2019 11:54

Cronologia

#1 Aggiornato da Enrico Zini 2 mesi fa

  • Versione prevista impostata a 0.4 Inventariazione

#2 Aggiornato da Enrico Zini 2 mesi fa

Tutti gli utenti sono su LDAP? Anche i referenti che non fanno parte di quella scuola?

#3 Aggiornato da Elena Grandi 2 mesi fa

Da discussione altrove:

Ad Octonet ci accedono
- i tecnici FUSS della Ripartizione informatica (che usano root oppure la loro utenza LDAP con tutte el autorizzazioni previste in OctoNet)
- i referenti tecnici FUSS delle scuole (docenti) che usano la loro utenza LDAP alla quale vengono assegnate solo alcune autorizzazioni in OctoNet (tipicamente gestione utenti e stampanti)

i tecnici hanno accesso root/sudo, i referenti no (non chiaro se si riferisce solo al server o anche ai client).

#4 Aggiornato da Paolo Dongilli 2 mesi fa

Elena Grandi ha scritto:

Ad Octonet ci accedono
- i tecnici FUSS della Ripartizione informatica (che usano root oppure la loro utenza LDAP con tutte el autorizzazioni previste in OctoNet)
- i referenti tecnici FUSS delle scuole (docenti) che usano la loro utenza LDAP alla quale vengono assegnate solo alcune autorizzazioni in OctoNet (tipicamente gestione utenti e stampanti)

i tecnici hanno accesso root/sudo, i referenti no (non chiaro se si riferisce solo al server o anche ai client).

Mi riferivo solo all'utenza root di Octonet che fa uso della master password:

La password di root di sistema, invece:
- sul server: è nota solo ai tecnici della ripartizione informatica
- sui client: è nota ai tecnici della ripartizione informatica e ad alcuni referenti tecnici delle scuole che hanno acquisito le competenze per lavorare sui client.

#5 Aggiornato da Elena Grandi 2 mesi fa

  • Assegnato a impostata a Elena Grandi

#6 Aggiornato da Elena Grandi 2 mesi fa

  • Assegnato a modificata da Elena Grandi a Paolo Dongilli

Che operazioni svolgono su octonet i referenti tecnici che non hanno la password di root?

#7 Aggiornato da Paolo Dongilli circa 2 mesi fa

Ad oggi, data la preparazione dei referenti tecnici, le funzionalità cui possono accedere sono:

- Utenti e Gruppi
- Computer gestiti
- Firewall
- Stampanti di rete

Un tecnico informatico, invece, autorizza la propria utenza a compiere tutte le operazioni.

Potenzialmente, un referente tecnico preparato (si contano sulle dita di una mano) potrebbero avere anche tutte le autorizzazioni al pari di un tecnico.

#8 Aggiornato da Elena Grandi circa 2 mesi fa

  • Assegnato a modificata da Elena Grandi a Paolo Dongilli

Quindi i tipi di operazioni che i referenti devono poter compiere sono:

Utenti e gruppi:

  • creazione e modifica di utenti (singoli e tramite import)
  • creazione di gruppi, e assegnazione di utenti ai gruppi

Computer gestiti:

  • visualizzare l'elenco delle macchine sulla rete
  • gestione dei cluster con aggiunta e rimozione delle macchine
  • accensione e spegnimento delle macchine
  • abilitazione / disabilitazione della navigazione internet

In quella pagina vedo anche la run di script sulle macchine: è in uso? devono poter continuare a farlo? e l'installazione di software?

Firewall:

  • aggiungere e rimuovere entries dai vari file di configurazione del firewall

Stampanti di rete:

  • accesso all'interfaccia di cups

È tutto? manca qualcosa? c'è qualcosa di troppo?

Questa è un'ottima occasione per rifinire meglio i permessi di accesso, ad esempio se ci sono pagine che al momento danno accesso ad alcune operazioni che vanno permesse ed altre che invece vanno limitate.

#9 Aggiornato da Paolo Dongilli circa 2 mesi fa

  • Assegnato a modificata da Paolo Dongilli a Elena Grandi

Elena Grandi ha scritto:

Quindi i tipi di operazioni che i referenti devono poter compiere sono:

Utenti e gruppi:

  • creazione e modifica di utenti (singoli e tramite import)

OK

  • creazione di gruppi, e assegnazione di utenti ai gruppi

OK

Computer gestiti:

  • visualizzare l'elenco delle macchine sulla rete

OK

  • gestione dei cluster con aggiunta e rimozione delle macchine

OK

  • accensione e spegnimento delle macchine

OK

  • abilitazione / disabilitazione della navigazione internet

OK

In quella pagina vedo anche la run di script sulle macchine: è in uso? devono poter continuare a farlo? e l'installazione di software?

Attualmente non lo usa praticamente nessuno, perché non sempre funzionante. Il run di script andrebbe rivisto e sottoposto ad un vostro ciclo di test/collaudo.

Installazione di software pure non viene usato. Pure questo dovrebbe essere sottoposto a vostro collaudo/revisione.

Firewall:

  • aggiungere e rimuovere entries dai vari file di configurazione del firewall

OK

Stampanti di rete:

  • accesso all'interfaccia di cups

OK

È tutto? manca qualcosa? c'è qualcosa di troppo?

Una funzionalità che manca è quella di accendere e spegnere i dispositivi radio 2.4 e 5 GHz negli accesspoint WiFi. Ve lo descrivo in un ticket a parte.

Altro per ora non mi viene in mente.

Questa è un'ottima occasione per rifinire meglio i permessi di accesso, ad esempio se ci sono pagine che al momento danno accesso ad alcune operazioni che vanno permesse ed altre che invece vanno limitate.

Per ora queste.

#10 Aggiornato da Elena Grandi circa 2 mesi fa

  • Assegnato a modificata da Elena Grandi a Paolo Dongilli

Paolo Dongilli ha scritto:

In quella pagina vedo anche la run di script sulle macchine: è in uso? devono poter continuare a farlo? e l'installazione di software?

Attualmente non lo usa praticamente nessuno, perché non sempre funzionante. Il run di script andrebbe rivisto e sottoposto ad un vostro ciclo di test/collaudo.

è previsto che lo sia (con delle modifiche)

una volta che è funzionante la run di script deve essere permessa a tutti? per qualunque script (anche caricato al momento dall'utente) o solo per un elenco di script predefiniti?

Installazione di software pure non viene usato. Pure questo dovrebbe essere sottoposto a vostro collaudo/revisione.

L'intenzione è di unificarlo al caso precedente.

#11 Aggiornato da Paolo Dongilli circa 2 mesi fa

  • Assegnato a modificata da Paolo Dongilli a Elena Grandi

Elena Grandi ha scritto:

una volta che è funzionante la run di script deve essere permessa a tutti? per qualunque script (anche caricato al momento dall'utente) o solo per un elenco di script predefiniti?

Direi di sì, per chiunque sia autorizzato ad utilizzare questa funzionalità. E chi ha avrà questa autorizzazione tipicamente è chi ad oggi conosce la pwd di root dei client.

#12 Aggiornato da Elena Grandi circa 2 mesi fa

  • Assegnato a modificata da Elena Grandi a Enrico Zini

Riassegno ad Enrico per chiedergli se secondo lui c'è tutto o ci siam dimenticati di qualcosa

#13 Aggiornato da Elena Grandi circa 2 mesi fa

  • Assegnato a modificata da Enrico Zini a Paolo Dongilli

Riassumendo i contenuti del ticket, queste sono le specifiche attuali sui permessi (una volta confermate e completate le salverò nel repository, come docs/permissions.rst, per documentazione futura)

Ruoli

  • Tecnici FUSS della Ripartizione Informatica (hanno root/sudo)
  • Referenti tecnici (non hanno root/sudo a parte qualcuno, che ha la password di root dei client)

Password

  • master: /etc/fuss-server/fuss-server.yaml contiene una master password che viene usata come password per un po' di servizi ed è anche la password root di octonet
  • root-server: root password del server
  • root-client: root password dei client

Autorizzazione

Tutte le password sono in LDAP: possiamo usare LDAP + master password come backend di autenticazione

Livelli di autorizzazione

  • master-root (root sul server) - corrispondente ai tecnici fuss
  • client-root (root sui client) - corrispondente ai referenti tecnici con password root-client: A
  • technician (amministrazione client, ma senza root) - corrispondente ai referenti tecnici: B
  • operator (gestione uso dei client)
  • user (cambio password — da valutare)

Permessi dei referenti tecnici

Utenti e gruppi:

  • creazione e modifica di utenti (singoli e tramite import) [AB]
  • creazione di gruppi, e assegnazione di utenti ai gruppi [AB]

Computer gestiti:

  • visualizzare l'elenco delle macchine sulla rete [AB}
  • gestione dei cluster/group con aggiunta e rimozione delle macchine [AB]
  • accensione e spegnimento delle macchine [AB]
  • abilitazione / disabilitazione della navigazione internet [AB]

Firewall:

  • aggiungere e rimuovere entries dai vari file di configurazione del firewall [AB]

Stampanti di rete:

  • accesso all'interfaccia di cups [AB]
  • Accendere e spegnere i dispositivi radio 2.4 e 5 GHz negli accesspoint WiFi (in futuro) [AB]

Run di script sulle macchine [A]

[aggiornamento: cambiati i livelli di autorizzazione dopo comunicazione via xmpp)

#14 Aggiornato da Elena Grandi circa 2 mesi fa

Rimangono delle domande:

  • ci sono referenti tecnici che oltre alle password di root dei client hanno anche la master-password?
  • i referenti tecnici che hanno la password di root dei client possono essere equiparati totalmente ai tecnici fuss, oppure è opportuno avere un livello di permessi intermedio da assegnare loro?

#15 Aggiornato da Paolo Dongilli circa un mese fa

  • Assegnato a modificata da Paolo Dongilli a Elena Grandi

Elena Grandi ha scritto:

Rimangono delle domande:

  • ci sono referenti tecnici che oltre alle password di root dei client hanno anche la master-password?

Di regola no, tranne qualche eccezione.

  • i referenti tecnici che hanno la password di root dei client possono essere equiparati totalmente ai tecnici fuss, oppure è opportuno avere un livello di permessi intermedio da assegnare loro?

E` opportuno avere un livello di permessi intermedio.

#16 Aggiornato da Elena Grandi 20 giorni fa

  • Versione prevista modificata da 0.4 Inventariazione a 0.9 Consolidamento

Esporta su Atom PDF