policykit
Inviato: gio 4 mar 2010, 15:19
Ho ricevuto in pm una richiesta di chiarimento su quanto in oggetto, inoltre ho letto qua e la cose che denotavano una scarsa comprensione del suddetto framework, quindi scrivo questa risposta in pubblico a beneficio di tutti:
Policykit e' una sorta di implementazione di mandatory access control in user space
pensato per le componenti di un desktop environment; che significa? significa che
quando un'applicazione di un DE (che gira completamente con utenza non privilegiata)
deve eseguire un'operazione privilegiata, contatta tramite un bus (di solito dbus)
una serie di applicazioni privilegiate, le quali (basandosi sull'identita' del richiedente,
l'azione richiesta e l'oggetto su cui intraprendere tale azione; quindi ad esempio
il richiedente e' il processo pippo, l'azione e' il mount di un dispositivo e l'oggetto
e' il dispositivo da montare) decidono se eseguire tale operazione e, in caso affermativo,
la eseguono, sgravando completamente il richiedente da questo compito (che non potrebbe
eseguire in quanto non ne ha i privilegi)
Architettura
ogni applicazione, che necessita di effettuare azioni che richiedano i permessi di root,
contatta hal (tramite dbus), il quale identifica il richiedente tramite consolekit (in base
a uid, pid e tipo di sessione, se attiva/non-attiva, remota/locale); a questo punto,
basandosi su richiedente, azione ed oggetto, hal tramite la libpolkit (una libreria che
permette di mappare azioni, oggetti, ecc.. e prendere decisioni su chi puo' fare cosa
su quale oggetto, basandosi sulle entry che trova nel db delle autorizzazioni) decide cosa
fare tra le seguenti due cose:
1) eseguire l'azione richiesta (in caso che nella configurazione di policykit non sia richiesta
autenticazione per eseguire quell'azione su quell'oggetto da parte del richiedente)
2) informare il richiedente che necessita di essere autenticato affinche' possa
essere eseguita l'azione richiesta; in tal caso il richiedente contatta un agent
di autenticazione (un processo non privilegiato), il quale, tramite la
libpolkit-grant (una libreria di autenticazione setuid che fa uso di pam e un helper
che gode dei privilegi di root tramite setgid) che verifica le credenziali e,
in caso positivo, tramite l'helper privilegiato, scrive una entry nel database
delle autorizzazioni (un db in cui viene mappato chi puo' fare cosa su quale oggetto),
per scrivere nel quale servono i privilegi di root (tale db e' lo stesso che utilizza
hal, tramite libpolkit, per decidere quali azioni intraprendere).
La suddetta entry specifica una delle seguenti 3 cose:
- quel dato richiedente (identificato dal pid e dallo
start time del processo) puo' eseguire quella data operazione su quel dato oggetto
(in virtu' dell'autenticazione effettuata)
- tutti i processi che si trovano nella stessa sessione desktop del richiedente
sono autorizzati ad eseguire quella data operazione su quel dato oggetto (in virtu'
dell'autenticazione effettuata)
- tutti i processi che girano con il medesimo uid del richiedente sono autorizzati ad
eseguire quella data operazione su quel dato oggetto (in virtu'dell'autenticazione
effettuata) e la suddetta entry nel db delle autorizzazioni non viene eliminata
al reboot del sistema
dopodiche' comunica al richiedente l'esito dell'autenticazione; in caso di esito positivo
il richiedente ricontatta hal e chiede di eseguire l'azione che gli aveva chiesto in
precedenza, hal verifica nel db delle autorizzazioni che il richiedente sia abilitato
(stavolta lo e' in virtu' della entry inserita dall'helper di cui sopra) ed esegue
l'azione richiesta
a grandi linee (alcuni aspetti li ho semplificato un po a favore della comprensione) questa
e' la struttura e il funzionamento di policykit.
Veniamo alle considerazioni:
Vantaggi
- permette un tipo di controllo piu' granulare rispetto a sistemi basati su gruppo di
appartenenza o su sessione
- tutto il codice privilegiato viene centralizzato (a differenza di meccanismi come setuid o sudo
che necessitano di dare privilegi ad ogni singolo processo che li richiede) quindi, in
configurazioni non banali, si eseguira' meno codice privilegiato; senza contare tutte
le positive implicazioni relative all'auditing del codice che necessita privilegi
- molto piu' semplice da configurare e da utilizzare rispetto a soluzioni in kernel space tipo
selinux
Svantaggi
- tutti i flussi di comunicazione, tra processi privilegiati e non, introducono potenziali buchi
di sicurezza
- molto meno robusto dal punto di vista della sicurezza rispetto a soluzioni in kernel space
tipo selinux (e meno sicuro anche rispetto all'amministrazione del sistema via cli con i tool
standard)
- richiede applicazioni scritte appositamente per supportare tale framework
- e' fortemente diseducativo per l'utente (vedere la parte "Considerazioni personali")
Considerazioni personali
In un contesto di sistemi che facciano uso di desktop environment complessi (quali gnome o kde)
e laddove l'utente non sia anche l'amministratore della macchina (in tal caso l'utente possiede
anche la password di root e quindi l'uso di policykit ha una valenza di forma piu' che di sostanza,
servendo unicamente a evitare di usare sistemi di gestione del sistema basati sulla cli),
policykit ha molto senso, in quanto permette di definire in maniera abbastanza granulare politiche
di sicurezza per N utenti, in maniera semplice e _relativamente_ sicura (rispetto a sistemi come
sudo).
Viceversa se parliamo di utenti che siano anche amministratori della propria macchina (il 99%
degli utenti home), policykit e', a mio avviso, una scelta pessima; lo e' per lo stesso motivo
per il quale lo sono tutte quelle cose che creano troppi layer d'astrazione che nascondono la
complessita' dell'ambiente sottostante; i motivi di questa affermazione li ho ripetuti decine
di volte, ma vediamo di fare un ripasso:
Chi sostiene la maggior semplicita' d'uso di sistemi complessi con piu' strati d'astrazione
sommati che nascondano all'utente finale il funzionamento del sistema, ha sempre anche usato
argomentazioni quali: "non tutti vogliono sapere come funziona un sistema ma molti lo vogliono
semplicemente usare", ok ma allora perche' se non funziona qualcosa non chiami un tecnico
specializzato piuttosto che metterci le mani tu? allora non vuoi solo essere un utente finale;
vuoi la strada semplice (non rendendoti conto che invece imbocchi quella difficile) e pensi
d'essere piu' furbo (quando in realta' sei solo piu' cretino perche' non perdi n tempo
all'inizio ma poi, sommando tutto il tempo perso dietro a problemi di cui non capivi un cavolo,
hai n+m tempo perso, con m che cresce ad ogni nuovo problema).
Quindi non prendiamoci per i fondelli con il discorso del "lui vuole solo usare quel software e
non vuole sapere altro", perche' non e' cosi', o almeno lo e' solo quando fa comodo.
Se veramente vuoi usare e basta senza saper nulla (esattamente come quando compri un'automobile
e se si rompe la porti dal meccanico/carroziere/gommista anziche' metterci le mani tu), allora
effettivamente e' piu' semplice da usare una distro con una UI molto astratta, ma se poi al
primo problema anziche' chiamare un tecnico (come faresti con qualsiasi altra cosa per la quale
vuoi essere solo un utilizzatore finale senza saper nulla) pretendi di metterci le mani tu, col
cavolo che e' piu' semplice.
Non esiste mai la via facile, in nessun caso; magari sembra facile e tu pensando di essere
furbo (quando in realta' dimostri solo d'esser cretino) credi di faticare meno, ma tutto quel
che ottieni e' farti il c**o a tarallo molto di piu' di chi ha preso la strada che a te sembrava
difficile.
L'unica via facile che esiste e' delegare la manutenzione ed essere realmente solo utlizzatori
finali; ma, se cosi' non e', la via piu' semplice e meno faticosa e' sempre quella con la curva
d'apprendimento piu' ripida che, una volta a regime, ti permette di risolvere qualunque problema
in pochi minuti.
il punto non e' se fai una certa operazione N o M volte al mese, ma se sei consapevole di come
funzioni quel che c'e' dietro quell'operazione; la "curva di apprendimento" di cui ho parlato
fino ad ora non e' un sacco tipo quello di babbo natale, pieno di nozioni tipo: "per fare questa
operazione fai prima questo, poi quello e poi quest'altro" (in tal caso il mio discorso non
avrebbe senso perche' ad ogni problema nuovo l'utente non saprebbe come risolvere e la curva
di apprendimento andrebbe su all'infinito); piuttosto e' una forma mentis, un modo di ragionare
che ti formi comprendendo come funziona intimamente il sistema che usi; questo ti permette di
affrontare problemi e risolverli anche quando il problema e' nuovo o quando non lo si affronta
da tanto tempo.
Ovviamente se si usano DE come gnome o kde (soprattutto quest'ultimo) che hanno una forte
integrazione con il sistema e con se stessi, anche se si e' amministratori della propria
macchina l'uso di policykit e' quasi d'obbligo.
N.B. un'obiezione che si potrebbe fare al suddetto discorso potrebbe essere: "non e' vero che
l'uso di policykit, nel caso in cui l'utente e' anche amministratore, ha una valenza di forma
piu' che di sostanza, perche' comunque, anche amministrando il sistema da cli, hai lo svantaggio
di dover essere root e di lanciare ogni tool da root (quindi la quantita' di codice che gira con
i massimi privilegi cresce, rispetto all'uso di un framework come policykit)", questo e' senza
dubbio vero, ma va considerato che i tool d'amministrazione di un sistema linux da cli, non sono
moltissimi, sono gli stessi da anni, e il loro codice ormai e' abbastanza stabile (dal punto
di vista della sicurezza); inoltre policykit spesso esegue con i massimi privilegi un bel malloppo
di codice (come ad esempio PackageKit) e non delle mere syscall (come selinux).
Policykit e' una sorta di implementazione di mandatory access control in user space
pensato per le componenti di un desktop environment; che significa? significa che
quando un'applicazione di un DE (che gira completamente con utenza non privilegiata)
deve eseguire un'operazione privilegiata, contatta tramite un bus (di solito dbus)
una serie di applicazioni privilegiate, le quali (basandosi sull'identita' del richiedente,
l'azione richiesta e l'oggetto su cui intraprendere tale azione; quindi ad esempio
il richiedente e' il processo pippo, l'azione e' il mount di un dispositivo e l'oggetto
e' il dispositivo da montare) decidono se eseguire tale operazione e, in caso affermativo,
la eseguono, sgravando completamente il richiedente da questo compito (che non potrebbe
eseguire in quanto non ne ha i privilegi)
Architettura
ogni applicazione, che necessita di effettuare azioni che richiedano i permessi di root,
contatta hal (tramite dbus), il quale identifica il richiedente tramite consolekit (in base
a uid, pid e tipo di sessione, se attiva/non-attiva, remota/locale); a questo punto,
basandosi su richiedente, azione ed oggetto, hal tramite la libpolkit (una libreria che
permette di mappare azioni, oggetti, ecc.. e prendere decisioni su chi puo' fare cosa
su quale oggetto, basandosi sulle entry che trova nel db delle autorizzazioni) decide cosa
fare tra le seguenti due cose:
1) eseguire l'azione richiesta (in caso che nella configurazione di policykit non sia richiesta
autenticazione per eseguire quell'azione su quell'oggetto da parte del richiedente)
2) informare il richiedente che necessita di essere autenticato affinche' possa
essere eseguita l'azione richiesta; in tal caso il richiedente contatta un agent
di autenticazione (un processo non privilegiato), il quale, tramite la
libpolkit-grant (una libreria di autenticazione setuid che fa uso di pam e un helper
che gode dei privilegi di root tramite setgid) che verifica le credenziali e,
in caso positivo, tramite l'helper privilegiato, scrive una entry nel database
delle autorizzazioni (un db in cui viene mappato chi puo' fare cosa su quale oggetto),
per scrivere nel quale servono i privilegi di root (tale db e' lo stesso che utilizza
hal, tramite libpolkit, per decidere quali azioni intraprendere).
La suddetta entry specifica una delle seguenti 3 cose:
- quel dato richiedente (identificato dal pid e dallo
start time del processo) puo' eseguire quella data operazione su quel dato oggetto
(in virtu' dell'autenticazione effettuata)
- tutti i processi che si trovano nella stessa sessione desktop del richiedente
sono autorizzati ad eseguire quella data operazione su quel dato oggetto (in virtu'
dell'autenticazione effettuata)
- tutti i processi che girano con il medesimo uid del richiedente sono autorizzati ad
eseguire quella data operazione su quel dato oggetto (in virtu'dell'autenticazione
effettuata) e la suddetta entry nel db delle autorizzazioni non viene eliminata
al reboot del sistema
dopodiche' comunica al richiedente l'esito dell'autenticazione; in caso di esito positivo
il richiedente ricontatta hal e chiede di eseguire l'azione che gli aveva chiesto in
precedenza, hal verifica nel db delle autorizzazioni che il richiedente sia abilitato
(stavolta lo e' in virtu' della entry inserita dall'helper di cui sopra) ed esegue
l'azione richiesta
a grandi linee (alcuni aspetti li ho semplificato un po a favore della comprensione) questa
e' la struttura e il funzionamento di policykit.
Veniamo alle considerazioni:
Vantaggi
- permette un tipo di controllo piu' granulare rispetto a sistemi basati su gruppo di
appartenenza o su sessione
- tutto il codice privilegiato viene centralizzato (a differenza di meccanismi come setuid o sudo
che necessitano di dare privilegi ad ogni singolo processo che li richiede) quindi, in
configurazioni non banali, si eseguira' meno codice privilegiato; senza contare tutte
le positive implicazioni relative all'auditing del codice che necessita privilegi
- molto piu' semplice da configurare e da utilizzare rispetto a soluzioni in kernel space tipo
selinux
Svantaggi
- tutti i flussi di comunicazione, tra processi privilegiati e non, introducono potenziali buchi
di sicurezza
- molto meno robusto dal punto di vista della sicurezza rispetto a soluzioni in kernel space
tipo selinux (e meno sicuro anche rispetto all'amministrazione del sistema via cli con i tool
standard)
- richiede applicazioni scritte appositamente per supportare tale framework
- e' fortemente diseducativo per l'utente (vedere la parte "Considerazioni personali")
Considerazioni personali
In un contesto di sistemi che facciano uso di desktop environment complessi (quali gnome o kde)
e laddove l'utente non sia anche l'amministratore della macchina (in tal caso l'utente possiede
anche la password di root e quindi l'uso di policykit ha una valenza di forma piu' che di sostanza,
servendo unicamente a evitare di usare sistemi di gestione del sistema basati sulla cli),
policykit ha molto senso, in quanto permette di definire in maniera abbastanza granulare politiche
di sicurezza per N utenti, in maniera semplice e _relativamente_ sicura (rispetto a sistemi come
sudo).
Viceversa se parliamo di utenti che siano anche amministratori della propria macchina (il 99%
degli utenti home), policykit e', a mio avviso, una scelta pessima; lo e' per lo stesso motivo
per il quale lo sono tutte quelle cose che creano troppi layer d'astrazione che nascondono la
complessita' dell'ambiente sottostante; i motivi di questa affermazione li ho ripetuti decine
di volte, ma vediamo di fare un ripasso:
Chi sostiene la maggior semplicita' d'uso di sistemi complessi con piu' strati d'astrazione
sommati che nascondano all'utente finale il funzionamento del sistema, ha sempre anche usato
argomentazioni quali: "non tutti vogliono sapere come funziona un sistema ma molti lo vogliono
semplicemente usare", ok ma allora perche' se non funziona qualcosa non chiami un tecnico
specializzato piuttosto che metterci le mani tu? allora non vuoi solo essere un utente finale;
vuoi la strada semplice (non rendendoti conto che invece imbocchi quella difficile) e pensi
d'essere piu' furbo (quando in realta' sei solo piu' cretino perche' non perdi n tempo
all'inizio ma poi, sommando tutto il tempo perso dietro a problemi di cui non capivi un cavolo,
hai n+m tempo perso, con m che cresce ad ogni nuovo problema).
Quindi non prendiamoci per i fondelli con il discorso del "lui vuole solo usare quel software e
non vuole sapere altro", perche' non e' cosi', o almeno lo e' solo quando fa comodo.
Se veramente vuoi usare e basta senza saper nulla (esattamente come quando compri un'automobile
e se si rompe la porti dal meccanico/carroziere/gommista anziche' metterci le mani tu), allora
effettivamente e' piu' semplice da usare una distro con una UI molto astratta, ma se poi al
primo problema anziche' chiamare un tecnico (come faresti con qualsiasi altra cosa per la quale
vuoi essere solo un utilizzatore finale senza saper nulla) pretendi di metterci le mani tu, col
cavolo che e' piu' semplice.
Non esiste mai la via facile, in nessun caso; magari sembra facile e tu pensando di essere
furbo (quando in realta' dimostri solo d'esser cretino) credi di faticare meno, ma tutto quel
che ottieni e' farti il c**o a tarallo molto di piu' di chi ha preso la strada che a te sembrava
difficile.
L'unica via facile che esiste e' delegare la manutenzione ed essere realmente solo utlizzatori
finali; ma, se cosi' non e', la via piu' semplice e meno faticosa e' sempre quella con la curva
d'apprendimento piu' ripida che, una volta a regime, ti permette di risolvere qualunque problema
in pochi minuti.
il punto non e' se fai una certa operazione N o M volte al mese, ma se sei consapevole di come
funzioni quel che c'e' dietro quell'operazione; la "curva di apprendimento" di cui ho parlato
fino ad ora non e' un sacco tipo quello di babbo natale, pieno di nozioni tipo: "per fare questa
operazione fai prima questo, poi quello e poi quest'altro" (in tal caso il mio discorso non
avrebbe senso perche' ad ogni problema nuovo l'utente non saprebbe come risolvere e la curva
di apprendimento andrebbe su all'infinito); piuttosto e' una forma mentis, un modo di ragionare
che ti formi comprendendo come funziona intimamente il sistema che usi; questo ti permette di
affrontare problemi e risolverli anche quando il problema e' nuovo o quando non lo si affronta
da tanto tempo.
Ovviamente se si usano DE come gnome o kde (soprattutto quest'ultimo) che hanno una forte
integrazione con il sistema e con se stessi, anche se si e' amministratori della propria
macchina l'uso di policykit e' quasi d'obbligo.
N.B. un'obiezione che si potrebbe fare al suddetto discorso potrebbe essere: "non e' vero che
l'uso di policykit, nel caso in cui l'utente e' anche amministratore, ha una valenza di forma
piu' che di sostanza, perche' comunque, anche amministrando il sistema da cli, hai lo svantaggio
di dover essere root e di lanciare ogni tool da root (quindi la quantita' di codice che gira con
i massimi privilegi cresce, rispetto all'uso di un framework come policykit)", questo e' senza
dubbio vero, ma va considerato che i tool d'amministrazione di un sistema linux da cli, non sono
moltissimi, sono gli stessi da anni, e il loro codice ormai e' abbastanza stabile (dal punto
di vista della sicurezza); inoltre policykit spesso esegue con i massimi privilegi un bel malloppo
di codice (come ad esempio PackageKit) e non delle mere syscall (come selinux).