La console è un privilegio: perché chiede un permesso a sé

Una console sembra uno schermo. La apri, compare una finestra, dentro scorre del testo. Dà la sensazione di "sto solo guardando".

Eppure una console è una shell. E la shell del server è il diritto più alto che esista su quella macchina.

Due poteri distinti

Cambiare impostazioni. Puoi fare ciò che l’interfaccia consente. I limiti sono chiari, perché li traccia l’interfaccia.

Aprire una shell. Puoi fare qualsiasi cosa. Anche ciò che l’interfaccia rifiuterebbe e ciò di cui non ha mai sentito parlare.

Questi due poteri non si contengono a vicenda. Avere l’uno non richiede l’altro e, cosa più importante: concedere l’uno non dovrebbe voler dire concedere l’altro.

La distinzione è reale e si vede nei ruoli predefiniti

Proxmox lega la console a un permesso tutto suo, non al generico "può cambiare". Che sia reale lo vedi nei ruoli predefiniti: il ruolo di amministratore di sistema porta i diritti di verifica, console e registro e non contiene il diritto di modifica.

È quindi una configurazione legittima dare a qualcuno il diritto di aprire una console senza il diritto di cambiare impostazioni. E anche il contrario.

La situazione comune che rende tutto questo importante

Proxmox permette di creare ruoli personalizzati, e un ruolo così è molto diffuso: un operatore che può cambiare le impostazioni di rete ma non deve raggiungere la shell del server.

È una richiesta ragionevole. Modificare la configurazione di rete ed eseguire qualsiasi comando sul server non sono la stessa cosa.

Ma se un prodotto ragiona "se può cambiare, può anche aprire la console", consegna a quell’operatore una shell di root senza accorgersene. Ottiene dal pannello ciò che in Proxmox non otterrebbe.

Il principio generale che ne discende

Un modello di permessi deve copiare la definizione della piattaforma, non parafrasarla.

Una porta che dice "più o meno la stessa cosa" funziona bene sulle installazioni ordinarie e nessuno se ne accorge. La falla si apre il giorno in cui viene creato un ruolo insolito. E quando quel giorno arriva, nessuno ricorda un’approssimazione scritta anni prima.

La stessa asticella vale per l’accesso ai file

Un altro dettaglio, perché sfugge spesso: l’accesso al file system del server equivale a una shell anche in sola lettura.

Il motivo è semplice: file delle password, chiavi e segreti del cluster stanno in quel file system. Chi ha un diritto di sola lettura e può leggere i file può già venire a sapere tutto.

L’accesso ai file non si può quindi concedere con un diritto di "guardare"; richiede la stessa asticella di una shell.

Che cosa fa Atlas

In Atlas la console, la shell remota e l’accesso ai file sono legati al solo permesso di console. Il diritto di modifica da solo non apre queste superfici.

Non è sempre stato così, e l’articolo deve finire onestamente: un tempo queste superfici accettavano anche il diritto di modifica. Il commento nel codice diceva la cosa giusta, diceva "l’equivalente è il permesso di console", ma il codice faceva altro.

È stato trovato misurando contro la definizione stessa di Proxmox, ed è stato corretto. Il risultato della misura era netto: Proxmox lega la shell al solo permesso di console e non accetta il diritto di modifica.

Va detto anche il peso reale così com’è: non era sfruttabile con i ruoli predefiniti, perché l’unico ruolo predefinito che contiene il diritto di modifica ha anche il permesso di console. Il rischio stava nei ruoli personalizzati, cioè nell’esempio dell’operatore di rete descritto sopra.

La lezione che ne segue vale anche per il prodotto stesso: che un commento abbia ragione non significa che il codice abbia ragione. I due vanno misurati separatamente.