Sì , è meno sicuro rispetto a quando si passa alla console di testo e si accede direttamente come root.

Prova 1:

Se hai effettuato il login come root in un terminale, un altro processo può inviare comandi a quel terminale.

Semplice dimostrazione del concetto:

1. Apri un terminale, inserisci nell'angolo in alto a sinistra dello schermo e passa a root.
2. Apri un secondo terminale che non si sovrappone al primo e digita:

$ xdotool mousemove 100 100 click 1 && xdotool key l && xdotool key s && xdotool key KP_Enter

xdotool

Prova 2:

xinput può leggere tutti i tratti della tastiera

Usa

$ xinput list

per identificare l'ID della tastiera e

$ xinput test id

per vedere quali tasti vengono premuti. Questo mostrerà anche le sequenze di tasti dal terminale su e rivelerà la tua password.

pagina man xinput

Se il tuo utente con privilegi limitati ha eseguito malware con i suoi privilegi, è possibile che quel malware abbia cambiato il percorso degli utenti e creato un eseguibile "su" diverso. Quando apri un terminale come utente con privilegi bassi, il malvagio su è ora il primo sul tuo percorso, quindi quando ti chiede la password hai perso il controllo della password.

Questo sarebbe evitato se si passasse a una console di testo e si fosse effettuato il login come root. Tuttavia, se passi a un accesso da console di testo come te stesso e su a root, ti trovi nella stessa situazione con X. Nota che potrebbe essere possibile che un malware intercetti il ctrl + alt + F1 e ti induca a inserire username e password ma sospetto che sarebbe molto più difficile e potrebbe richiedere più privilegi.

Si noti inoltre che le escalation di privilegi locali sono molto comuni, quindi una volta che il malware è in esecuzione come qualsiasi utente, è possibile che quel malware sia in grado di ottenere la root attraverso l'escalation dei privilegi.

Non sono molto conosciuto con gli interni di Linux in larga misura, quindi prendi questa risposta con un pizzico di sale.

Quando si accede a X server come utente normale, tutti i processi spawnati sono dei privilegi concessi a quell'utente. I processi hanno accesso limitato al sistema, la cui estensione è imposta dalla configurazione del sistema operativo, ma sono liberi di interagire con altri processi utente. Per questo motivo, lo spazio di memoria di processo è accessibile e molto probabilmente scrivibile da tutti gli altri processi di proprietà dell'utente. Quando si elevano i privilegi eseguendo il programma su, il nuovo sottoprocesso, il thread, qualunque esso sia, viene avviato dal processo padre in esecuzione come utente normale.

Con questo in mente, è possibile immaginare uno scenario in cui un'iniezione di codice è fatta in questo processo genitore, al fine di ottenere l'accesso allo spazio di memoria interno di quel processo vittima. In tal caso, è teoricamente possibile intercettare la sessione e privilegiare il "token" per ottenere l'accesso come root.

Posso vederlo fatto in due modi diversi: - Impostare un gancio per l'avvio del programma su e deviare il flusso per elevare diversi processi, anziché solo quello desiderato. - Intercetta una sessione attiva e inietta una richiesta per generare o elevare un altro processo.

Entrambi questi scenari richiedono l'esecuzione di codice arbitrario su una macchina vittima, quindi sarebbe una fase successiva del compromesso. Potrebbe fare la differenza se esegui X o meno, in un caso che è più difficile conoscere un processo corretto da iniettare, piuttosto che bash predefinito.

In ogni caso, penserei che sia fattibile per eseguire un simile attacco, ma il codice per farlo dovrebbe essere abbastanza mirato, e a meno che tu non sia una vittima di una campagna APT, le possibilità di qualcuno che fa il tifo al tuo casella rubando il comando 'su -' non sono vicini a nessuno.

Non ho alcuna conoscenza pratica su come estrarre una simile bravata su linux, quindi se mi sbaglio riguardo ai punti precedenti, sentiti libero di correggermi.

L'uso di root (nel terminale) in un account a livello di utente potrebbe darti dei dati non sicuri che potrebbero causare l'exploit di malware durante lo sfruttamento di cross-terminal. Quindi, in pratica basta usare l'accesso completo alla radice.

Passare alla root in un account a livello utente è una cosa abbastanza dura da fare. Quindi, è meglio se passi a root ogni volta che accedi semplicemente - >

Prima modifica il file /etc/login.defs e decommenta la seguente riga (rimuovi il '#' in primo piano):

NO_PASSWORD_CONSOLE tty1:tty2:tty3:tty4:tty5:tty6

Devi farlo in modo che non chieda una password dopo aver effettuato l'accesso.

In secondo luogo, modifica / etc / inittab. Questo file è un po 'complicato, quindi ti aiuta se hai familiarità con esso un po', ma se non stai lavorando solo sulla riga seguente:

c1:12345:respawn:/sbin/agetty 38400 tty1 linux

Vuoi dire al programma agetty di eseguire un programma di login automatico (lo scriveremo di seguito). Sostituisci la riga sopra con il seguente:

c1:12345:respawn:/sbin/agetty -n -l /usr/sbin/autologin 38400 tty1 linux

Il programma / usr / sbin / autologin non viene fornito con il tuo sistema, devi scriverlo e compilarlo da solo, ma è piuttosto facile. Prima crea un file di testo vuoto e aggiungi i seguenti contenuti:

int main() 
{
  execlp( "login", "login", "-f", "shafiq", 0);
}

Sostituisci shafiq con il nome dell'utente che vuoi accedere automaticamente e salva il file come autologin.c.

Quindi compilare il programma in questo modo (devi essere root per farlo funzionare):

cc autologin.c -o /usr/sbin/autologin

E questo è tutto. Quando la tua macchina termina il boot, eseguirà il programma di autologin che effettuerà l'accesso come utente specificato in autologin.c e poiché hai modificato /etc/login.defs non chiederà la password.

Ora per eseguire un programma dopo aver effettuato l'accesso è sufficiente modificare .bash_profile nella directory home dell'utente (creare il file se non esiste) e aggiungere il comando che si desidera eseguire alla fine di tale file, ad esempio è il mio .bash_profile, tutto ciò che fa è eseguire pico:

pico

E se non ti senti sicuro di farlo, prova a crittografare il BIOS durante l'avvio. E vediamo se qualcuno può aprire il tuo dispositivo anche nella fase iniziale di avvio del dispositivo che stai utilizzando.

Saluti.

Sì, sarebbe più sicuro aprire una nuova console e accedere come root. Quando si utilizza su - si esegue il piping di una sessione root alla sessione utente normale. Se c'era un utente malintenzionato che aveva accesso alla shell al tuo account normale, poteva dirottare quella sessione che hai con root. Potrebbe non essere in grado di dirottare la sessione X, tuttavia potrebbe mettere in grado la connessione tra utente normale e utente root.