sudo e .profile/.bashrc consentono una banale escalation dei privilegi?

Qualsiasi cosa tu possa fare su un account compromesso, può farlo anche un utente malintenzionato.

Fondamentalmente, questo è perché l'isolamento dei provider Linux tra gli utenti, non tra i singoli processi in esecuzione come lo stesso utente. Qualsiasi processo in esecuzione come un determinato utente è considerato dotato di capacità equivalenti a qualsiasi altro processo in esecuzione sotto quell'utente.

È vero che l'eseguibile sudo di sistema può essere aggirato in questo modo?

Sì, e anche in altri modi. Se elevi i privilegi a root su un account non privilegiato compromesso, comprometti root. Se elimini i privilegi da root usando su a un account non privilegiato, comprometti anche root! Non puoi mai elevare in sicurezza i privilegi su un account non attendibile. Mentre è possibile sfruttare il sistema usando PATH , è anche possibile dirottare il processo bash stesso per annusare l'input dei tasti. Disabilitare l'esecuzione con noexec non è inoltre utile perché gli interpreti (bash, python, perl, ecc.) continueranno a funzionare. Il noexec l'opzione non è e non è mai stata progettata come funzionalità di sicurezza, nonostante sia regolarmente spacciata come tale.

Un elenco incompleto di modi in cui un utente malintenzionato potrebbe dirottare l'uso di sudo o su :

• Usando il LD_PRELOAD variabile sul processo padre (ad es. bash ).

• Agganciare il processo genitore con ptrace() o process_vm_writev() .

• Sniffare o inserire sequenze di tasti nell'emulatore di terminale utilizzando il protocollo X11.

• Creazione di alias o funzioni per racchiudere l'attuale sudo eseguibile.

Li ho spiegati in modo più dettagliato nella mia risposta a un'altra domanda.

Perché i sistemi desktop Linux, per impostazione predefinita, sono configurati in modo così facilmente sfruttabile?

L'innalzamento dei privilegi su un account non attendibile non è qualcosa supposto da fare. Per non parlare del fatto che Linux desktop è un ripensamento nel grande schema dell'architettura generale * nix. È un fallimento del teatro di sicurezza che ripete incessantemente lo stesso cattivo consiglio, non un fallimento dell'architettura di sicurezza di Linux stesso. Le persone dicono ripetutamente di usare sudo per root perché molti nuovi utenti eseguiranno invece tutto come root, anche i loro browser! In questo caso, è meglio usare sudo . È dannoso nel caso in cui l'utente sia già abbastanza intelligente da non usare root per tutto.

Nota che sudo è altamente configurabile e può essere progettato per consentire solo determinati comandi. Questo è dove brilla davvero. Puoi configurare sudo per consentirti solo di eseguire apt-get update come root (con o senza password) e nega tutto il resto. Ciò impedirebbe inoltre a un utente malintenzionato di fare qualcosa di diverso da... beh... fare un aggiornamento del software.

È importante ricordare che, anche se lo configuri per consentire solo l'esecuzione di determinati comandi come root, puoi comunque spararti sui piedi se inserisci nella whitelist programmi che non sono progettati per essere eseguiti come root tramite un utente non attendibile. Ho visto un esempio di vita reale di qualcuno che cercava di eseguire VeraCrypt in questo modo e ho spiegato perché non è sicuro. L'idea era che VeraCrypt fosse sicuro da eseguire come root, quindi dovrebbe essere sicuro usare sudo per elevarlo a root come utente non fidato e senza privilegi. Si scopre che l'idea è errata e consente una banale escalation dei privilegi!

Il modo predefinito per invocare sudo non dovrebbe garantire che sia, in effetti, l'eseguibile fornito dal sistema (nessuno digiterà /usr/bin/sudo ogni volta)?

Digitare il percorso completo non ti proteggerà! Puoi facilmente creare una funzione che contenga un / iniziale , e sovrascriverà il vero eseguibile. Anche se l'eseguibile si è assicurato che sia autentico e ha tentato di sconfiggere lo sniffing, un processo dannoso potrebbe dirottare il bash elabora e sniffa le sequenze di tasti indipendentemente da sudo , rendendo impossibile il rilevamento dal suo punto di vista.

$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!

In un tale ambiente, sembra che l'utilizzo di sudo sia fondamentalmente insicuro e sarebbe meglio abilitare l'accesso come root e accedere su un TTY separato.

Questo è sempre il caso. Si noti che anche l'accesso a un altro TTY non è perfettamente sicuro. Dovresti utilizzare SAK, la combinazione Secure Attention Key, per assicurarti di interagire con una vera sessione di accesso (agetty o logind , Per esempio). SAK è una combinazione di tasti che il kernel ascolta (e quindi non può essere repressa dallo spazio utente). Quando lo rileva, interromperà ogni processo nell'attuale TTY, facendo apparire il prompt di login. Se sei passato a un TTY autentico e senza compromessi, il prompt scomparirà e riapparirà. Se sei su un TTY dirottato, interromperà il processo dannoso e ripristinerà la vera richiesta di accesso.