Ripesco una mia vecchia discussione per
Xephyr. Permette l'esecuzione di un server X dentro un altro server X, come Xnest, rispetto a cui dovrebbe essere più avanzato.
Per installarlo:
- Codice: Seleziona tutto
# apt-get install xserver-xephyr
Il motivo di un server annidato è presto detto: su Xorg c'è un access control attivo soltanto tra display diversi (e di default un utente può connettersi solo al suo display), ma a parte questo non c'è nessuna misura di sicurezza. Se cioè si permette l'accesso a un utente, allora chi può connettersi al display avrà accesso a tutte le risorse del display. E ogni applicazione attiva su un display può (potenzialmente) spiare qualsiasi altra, anche riguardo l'input fornito.
E questo è ancora più indesiderabile in caso di ssh connesso a un host remoto con una redirezione su X.
EDIT: Esiste in realtà un'ulteriore forma di controllo con la suddivisione delle applicazioni connesse al display tra trusted e untrusted, così che quelle untrusted non possano immettere né osservare l'input di quelle trusted. È questa la configurazione standard quando si usa ssh e si redirige l'input con l'opzione -X (se si utilizza -Y si utilizza invece la "trusted", il che significa che l'applicazione avrà accesso a tutte le risorse del display). Usando -X l'uso di
Xephyr potrebbe essere ridondante, ma potrebbe essere usato per avviare un'intera sessione grafica e ridirigerla su
Xephyr.
--- --- --- --- ---
Comunque senza tirare in ballo ssh, per ora, se si vuole confinare un'applicazione locale a essere eseguita con i permessi di un altro utente, sudo lo permette una volta configurato sudoers (via visudo). Ma in caso di applicazioni grafiche resta il problema dell'inaffidabilità di Xorg.
Con
Xephyr invece, dall'interno della sessione dell'utente1 (supponendo che sia su display :0, ma basta controllare $DISPLAY), apriamo un nuovo display (che io considero :1 da qui in avanti) che sarà contenuto in una finestra della sessione corrente:
- Codice: Seleziona tutto
$ Xephyr -ac -reset -terminate -nolisten tcp -screen XRESxYRES :1 &
(-ac disabilita l'access control su
Xephyr, -reset e -terminate assicurano la chiusura quando esce l'ultimo client connesso, -nolisten tcp per disabilitare l'ascolto su TCP (IPv4 e IPv6) visto che si usa localmente, -screen imposta la risoluzione da usare per
Xephyr, :1 è l'ID del nuovo display/finestra da usare e dev'essere libero).
Dopodiché è possibile eseguire applicazioni come un altro utente con sudo, collegandolo al display appena aperto:
- Codice: Seleziona tutto
$ DISPLAY=:1 sudo -u utente2 -- applicazione-non-così-fidata
L'applicazione-non-così-fidata non potrà leggere né inviare tasti al di fuori di
Xephyr, e avrà i permessi per leggere e scrivere nella sola home dell'utente2.
È da notare che l'opposto non vale, ovvero l'applicazione può essere (potenzialmente) "spiata" da tutte le applicazioni dell'utente1 (e non solo, visto l'access control di
Xephyr disabilitato). Quindi per eseguire al sicuro una singola applicazione grafica, l'unica è utilizzare un account dedicato su display dedicato.
--- --- --- --- ---
Per non disattivare l'access control nemmeno in
Xephyr, si può utilizzare xauth per creare un nuovo file Xauthority, lasciandone la lettura al solo gruppo dell'utente2. Di seguito presento l'alternativa, tutto dev'essere eseguito sempre dall'utente1.
Creo un file vuoto con nome desiderato, ma in un percorso leggibile da entrambi utente1 e utente2, da usare come Xauthority per il nuovo display:
- Codice: Seleziona tutto
$ touch /tmp/.xauth-xephyr.1
Aggiungo l'autorizzazione, usando il protocollo basato sul "magic cookie" (il "punto" è un alias), che viene generato da mcookie e passato (in chiaro...) a xauth per aggiungerlo al nuovo Xauthority:
- Codice: Seleziona tutto
$ xauth -f /tmp/.xauth-xephyr.1 add "$(hostname)/unix:1" . "$(mcookie)"
Modifico i permessi del file, permettendone la lettura al gruppo (di default xauth dovrebbe toglierla), e cambio il gruppo in quello dell'utente2:
- Codice: Seleziona tutto
$ chmod 640 /tmp/.xauth-xephyr.1
$ chgrp utente2 /tmp/.xauth-xephyr.1 # utente1 deve appartenere al gruppo di utente2 o servono i privilegi di admin
Avvio
Xephyr con gli stessi parametri di prima, a parte che non c'è -ac (perché l'access control resta attivo anche lì) e utilizzo il file authority con -auth:
- Codice: Seleziona tutto
$ Xephyr :1 -reset -terminate -nolisten tcp -screen XRESxYRES -auth /tmp/.xauth-xephyr.1 &
Lancio sempre come utente1, collegandomi al display e autenticandomi con il file Xauthority indicati, l'applicazione con sudo:
- Codice: Seleziona tutto
$ DISPLAY=:1 XAUTHORITY=/tmp/.xauth-xephyr.1 sudo -u utente2 -- applicazione-non-così-fidata
Per avere maggiore controllo è possibile avviare anche un window manager, al posto dell'applicazione, con pannello e menù già integrati, come blackbox. E poi avviare le applicazioni dentro
Xephyr da lì in modo grafico.
L'unico problema rimasto è l'esecuzione di applicazioni Qt.
