È sicuro lasciare una shell root in esecuzione in una sessione di schermo separata?

Sono curioso della sicurezza di lasciare una shell root in esecuzione in una sessione di schermo separata. Di solito non lo faccio mai.

A parte la possibilità che il mio account utente non root venga compromesso (password esposta, chiave ssh compromessa, ecc.), Ci sono altri vettori di accesso a una sessione di schermo distaccata e protetta da password di cui dovrei essere preoccupato, o può uno schermo staccato la sessione è considerata inerte?

Penso che sia un problema di sicurezza, perché "A parte il potenziale del mio account utente non root compromesso" può essere piuttosto grande.

Ma ci sono altri rischi maggiori oltre a quello. Ad esempio, ora ti sei aperto a un exploit teorico che consente di modificare le autorizzazioni nella directory del socket dello schermo ( /var/run/screensul mio sistema, ma a volte /tmpviene utilizzato). Quell'exploit ora ha un percorso per ottenere il root, che non potrebbe altrimenti.

sudoha altri vantaggi, se puoi allenarti ad usarlo per ogni comando piuttosto che farlo sudo su -. Registra le azioni (che, a meno che tu non stia effettuando la registrazione in remoto, non aumenta significativamente la sicurezza, ma ti dà una traccia di ciò che hai fatto). E aiuta a prevenire gli incidenti richiedendo un'escalation intenzionale per ogni comando, piuttosto che passare a una sessione interamente privilegiata.

Se hai una shell di root in una sessione dello schermo (scollegata o meno, protetta da password o meno) e il tuo screeneseguibile non è setxid, un utente malintenzionato che ottiene i tuoi privilegi può eseguire comandi in quella shell. Se non altro, possono farlo rintracciando il processo dello schermo.

Se screen è setuid o setgid e la sessione è scollegata e protetta da password, in linea di principio richiede la password dello schermo per eseguire i comandi in quella shell. Se questo principio è valido, qualcuno che ha solo compromesso il tuo account dovrebbe mettere in atto un trojan e attendere che tu digiti la password. Tuttavia, la superficie di attacco (ovvero il numero di punti in cui le cose possono andare storte a causa di un bug o di un'errata configurazione) è scomoda. Oltre alle funzionalità di sicurezza di base del sistema, ti stai fidando:

• schermo per ottenere il controllo della password corretto.
• schermo per impedire l'accesso alla sessione con altri mezzi.
• schermata per utilizzare correttamente i meccanismi di controllo degli accessi al sistema operativo (ad es. permessi sui tubi).
• il kernel per eseguire correttamente i controlli di sicurezza di ptrace (questa è una frequente fonte di vulnerabilità).
• la conchiglia non fa nulla di stupido.
• qualche altra caratteristica per non morderti.

"Qualche altra caratteristica per non morderti": sì, è vago. Ma è sempre una preoccupazione per la sicurezza. Potresti essere tentato di liquidare questo come un semplice pio desiderio, ma hai davvero pensato a tutto? Per esempio…

Finché è possibile scrivere sul dispositivo terminale, è possibile iniettare dati nell'input della shell. Sotto la configurazione predefinita dello schermo sul mio computer:

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

Questo si inserisce ␛]lfoobar␛lnel flusso di input della shell. \ekè la sequenza di controllo che consente a un'applicazione (o qualsiasi cosa in grado di scrivere sul dispositivo terminale) di impostare il titolo della finestra (vedere la sezione "Denominazione delle finestre" nel manuale dello schermo ), e \e[21tfa in modo che il terminale riporti il ​​suo titolo sull'input standard dell'applicazione ( schermo non documenta questa sequenza, ma non attuarlo; si può trovare sotto CSI Ps ; Ps ; Ps ; tnella lista sequenze di controllo xterm in realtà, almeno sotto schermo 4.0.3, tutti i caratteri di controllo vengono eliminati dal titolo segnalato, in modo che la shell legge. lfoobar(supponendo che ␛]non sia vincolato a un comando di modifica) e nessuna nuova riga. Quindi l'attaccante non può effettivamente eseguire un comando in quel modo, ma può riempire un comando comechmod u+s /bin/sh seguito da un sacco di spazi e un prompt dall'aspetto probabile.

Lo schermo implementa diverse altre sequenze di controllo rischiose simili, non so quale sia la loro potenzialità per le vulnerabilità. Ma si spera ormai che tu possa vedere che la protezione offerta dalle password delle sessioni dello schermo non è eccezionale. Uno strumento di sicurezza dedicato come sudo ha molte meno probabilità di avere vulnerabilità.

Le pipe create dallo schermo sono accessibili solo dal proprietario, quindi questo non dovrebbe essere un problema di sicurezza.