In breve: sì, stare su un account con privilegi ridotti ti aiuta a proteggerci dal malware, ma non ti rende immune. Come ogni misura di sicurezza, nessuna cosa ti manterrà al 100% cassetta di sicurezza.

TL; DR: in esecuzione su un account con privilegi ridotti (aka " principio di privilegio minimo ") dovrebbe far parte di una colazione equilibrata che include anche buone configurazioni firewall; strumenti per monitorare processi, risorse di sistema, porte aperte, traffico di rete, ecc. per attività sospette; un criterio per eseguire solo eseguibili firmati, configurazione del modulo del kernel sicuro SELinux, mantenere il sistema operativo e l'applicazione aggiornati con patch di sicurezza e altro.

La tua domanda è molto ampia per rispondere direttamente. Invece lo romperò in diversi casi in base alla configurazione del sistema e a ciò che l'aggressore sta cercando:

Caso n. 1: Personal computer

Diciamo che il computer Linux in questione sia il mio portatile personale. Uso efficacemente questo come sistema a utente singolo e digito sudo abbastanza regolarmente, quindi tutte le cose che hai menzionato si applicano. Inoltre, se l'attaccante sta cercando di rubare le mie informazioni personali come numeri di carte di credito, documenti fiscali, ecc., Questo è tutto nella mia home directory dove questo utente ha accesso ad esso. Se è ransomware e vuole crittografare i miei file personali - la stessa cosa. Vogliono installare un processo in background per rendere il mio computer parte di una botnet, che non ha bisogno di permessi speciali.

Caso 2: server, account amministratore

Il danno di avere malware sull'account di un amministratore è inferiore al caso dell'utente finale visto che l'account admin probabilmente non contiene dati preziosi. ma anche così, un utente malintenzionato può probabilmente fare dei danni avendo uno sniffer di pacchetti all'interno della rete, o aprendo una porta che permetta all'utente malintenzionato di eseguire test della penna all'interno della rete. Qui puoi fare affidamento sulla configurazione del tuo firewall per proteggerti da alcuni di questi e, si spera, notificarti all'attività sospetta in modo da poterlo pulire.

Se l'amministratore digita sudo su base regolare, allora sì, probabilmente sei nei guai.

Caso n. 3: server, account non amministratore

Immagina che l'uso in questione sia tomcat - un utente con privilegi molto bassi che esegue le applicazioni del server web. Questo è il caso che la gente di solito pensa quando parla di " principio di privilegio minimo ", e ottenere malware su questo account sarà il meno pericoloso dei tre casi che ho menzionato.

Considera inoltre che esistono exploit Escalation di privilegi per Linux che consentirebbero a un utente con privilegi limitati di aggirare la sicurezza del sistema operativo e trasformarsi in root. In generale, tenersi aggiornati con le patch di sicurezza ti protegge da questo, ma gli attori abbastanza ricchi da acquistare exploit sul mercato nero sapranno di exploit zero-day che non sono pubblicamente noti e non sono stati corretti.

We always hear...

Lo facciamo? Io no.

Installare un programma non attendibile come utente normale è una pessima idea con Linux come con Windows o Mac: questo programma ha accesso a tutti i tuoi dati e può cancellare questi dati, inviare questi dati a qualcun altro ecc. Inoltre può fare screenshot, controllare altre applicazioni in esecuzione sullo stesso schermo di X windows (anche se funzionano come un utente diverso), può afferrare chiavi (es. keylogger), ... Per i dettagli vedere The Linux Security Circus: sull'isolamento della GUI .

A parte questo, abbiamo regolarmente bug di escalation di privilegi anche in bug di Linux che possono essere usati da un utente non privilegiato per ottenere autorizzazioni root o persino a livello di kernel.

Quindi non installare programmi non attendibili su alcun tipo di sistema, a meno che tu non voglia compromettere questo sistema oi dati memorizzati su di esso.

Questo è un caso orribile di Security Theatre

Security Theater is the practice or belief of something that looks like it improves security, but in reality does little/harm to it.

Questa falsa credenza è stata in circolazione finchè la seguente diceria

Linux has no viruses because of it's permission system

È quasi buono come dire

I don't have a virus on my computer because I don't see anything flashing

Solo perché non lo vedi, non significa che sia vero. Chiudere gli occhi non ti protegge dall'intruso.

In tutta la realtà Linux, Mac OS, Windows, Android, Xbox, tutto ha vulnerabilità che consentirebbero l'escalation a un livello di controllo del sistema.

TUTTAVIA solo perché l'attacco non si risolve da solo a livello di sistema non significa che non sia ESTREMAMENTE pericoloso. Queste applicazioni con accesso a livello utente possono ancora rubare le tue informazioni, registrare ogni tua mossa e conservare i tuoi dati per il riscatto! Tutto senza MAI escalation perché si tratta dei dati a cui ha accesso solo come utente.

Questi fatti sono validi per QUALSIASI SO a prescindere dal dispositivo. Se si ha accesso alla memoria, ha accesso alla memoria. Ciò significa che anche se non puoi vederlo, ha ancora accesso ad esso.

The Good News

Dato che sei un utente normale significa che l'attacco non è già ai privilegi di root, il che significa che l'accesso è limitato agli utenti e aiuta proteggere altri utenti sul sistema. Ovviamente questo non significa che l'escalation non può accadere, significa solo che è molto più difficile.

Il sistema stesso è al riparo da account che non sono equivalenti a livello di root, ma questo non aiuta molto su un desktop dove la maggior parte di ciò che ti interessa sono i tuoi dati personali e ti autentichi regolarmente per diventare root dal tuo account .

Se qualcuno ha un account su un sistema multiutente configurato correttamente e non hanno i privilegi di sudo o la password di root, quindi escludi eventuali bug nel software privilegiato, non c'è nulla che l'utente possa fare che darà loro controllo della macchina. Un account utente che potrebbe aver installato software dannoso dovrebbe essere considerato un potenziale aggressore dal resto del sistema.

Sul mio desktop, ho aggiunto un account non privilegiato a cui posso sudo , ma non può% ro_de% per root. A volte eseguo software di cui mi fido un po ', ma non del tutto, sotto quell'account, esp. se usa la rete.

In teoria, dato che concedo all'account l'accesso al mio server X, potrebbe aumentare i suoi privilegi con gli attacchi di simulazione di appunti / sequenza di tasti. È nello stesso gruppo Unix del mio account normale e sono sicuro di non aver rimosso completamente i permessi di scrittura di gruppo da alcuni file importanti, ma ho fatto sudo e alcuni altri file importanti. Quindi è un ostacolo in più che alcuni malware potrebbero non aver previsto.

La ricetta qui, anche se non è affatto infallibile, è incompleta o sbagliata.

L'installazione di software non affidabile in tuo account non privilegiato è un disastro.

Installandolo in un altro account non privilegiato preparato con cura? Meno rischioso, ma assolutamente non garantito.

Se:

• sei sicuro che il tuo sistema sia configurato come un sistema multiutente sicuro (nessun bit casuale di accesso in scrittura alle directory di sistema, probabilmente pieno di Linux SE)
• Crea un account che non condivide alcun gruppo con il tuo account.
• Hai impostato con cura l'accesso su tutti i tuoi dati per essere qualcosa come 0770 - nessun accesso a "altro" -

quindi sei sicuro quanto qualsiasi ambiente che dipende dalla sicurezza multiutente su un sistema Linux condiviso. Tuttavia, questi proiettili rappresentano un bel po 'di lavoro. Non sarebbe più semplice avviare un CD o una VM?

isn't it possible for a low-level user to install a script with a keylogger, for example, that waits for an su - or sudo call and takes system control from there?

No - e hai già dato la risposta, perché questo è "fuori dal loro ambito di autorizzazione". Linux è sempre stato un sistema multiutente e (quasi) tutto ciò che può essere implementato al di fuori del kernel è implementato al di fuori del kernel e quindi soggetto ai vincoli del sistema di permessi.

Un utente può installare / eseguire codice che distrugge i propri dati, ma l'unico modo in cui può essere fatto un ulteriore danno è sfruttando una vulnerabilità nell'implementazione.

Sì, se quell'utente ha accesso "su" o sudo, è possibile che il malware possa cambiare il percorso in modo che punti al proprio codice invece di su / sudo e quindi MITM l'interazione. ma questo è un po 'più complicato da fare in pratica, dal momento che su o sudo dovrebbe essere invocato dall'albero del processo che già contiene il malware in esecuzione.