I file utente sono ancora privati ​​quando esistono due utenti sudo in Ubuntu?

31

Sto condividendo il mio PC Ubuntu personale con uno dei miei colleghi.

Ho creato un altro utente con una password diversa (lo sa ovviamente) e l'ho aggiunto sudoerall'elenco.

Dato che ci sono due sudoutenti in un singolo sistema Ubuntu:

  • I file privati ​​(specificati dai proprietari e dalle autorizzazioni) di qualcuno di questi utenti sono ancora privati?

  • Posso modificare i file del mio collega tramite sudocomando, anche sudo suo viceversa?

permissions  sudo 
— Jizhou Huang
fonte
— pa4080,
6
Ubuntu consente di crittografare una cartella principale durante la creazione dell'utente. Questa potrebbe essere esattamente la funzione necessaria qui.
— Thorbjørn Ravn Andersen,
— G-Man dice "Ripristina Monica" il
@ ThorbjørnRavnAndersen Dopo aver crittografato la cartella home, posso ancora accedere ai file all'interno come ho fatto prima?
— Jizhou Huang,
3
Perché non rimuovi l'accesso sudo dall'altro utente e diventi l'unico amministratore? Qualunque sia la ragione per cui l'altro utente ha bisogno di sudo, puoi sistemarlo in modo che non abbia bisogno di sudo (montaggio, stampa, aggiornamenti automatici, ecc.)
— Xen2050,

Risposte:

51

Se il tuo collega è nella lista dei sudoers è root quanto te se lo vuole (e può anche impersonare te), e quindi può vedere tutto.

Questa è la peggior configurazione che puoi avere se vuoi la privacy dell'utente. Dovresti leggere definitivamente come funziona la gestione degli utenti su Linux. Ecco alcuni articoli con cui puoi iniziare:

E anche allora se qualcuno ha accesso fisico alla macchina in questione, non c'è privacy, potrebbe cadere all'avvio in una shell di root e vedere tutto a prescindere da cosa, e se questo fosse protetto da password potrebbe comunque usare una chiavetta USB e vai avanti così.

Quindi la cosa migliore in quel caso è la corretta gestione degli utenti, password per root e unità crittografata e / o directory home crittografate.

— Videonauth
fonte
2
Anche se assicurati sudo -iche non funzioni :)
— Wilf
3
Mentre la configurazione più semplice e comune dei sudoer è quella di consentire temporaneamente a un elenco di utenti di disporre dei privilegi di root, i sudoer consentono un controllo accurato dell'accesso. Ad esempio, è possibile specificare che un utente può eseguire solo determinati comandi specifici come root. Se ti occupi solo di consentire a un utente di eseguire comandi che non consentono la creazione di una shell root o la creazione di un accesso root persistente oltre l'ambito dei comandi che desideri consentire, puoi evitare di dare loro l'accesso root in generale.
— bgvaughan,
19

Una semplice alternativa è quella di mantenere i tuoi dati privati ​​in un file crittografato (potrebbe essere un file di archivio tar, che crittograferai, ad esempio con gpg). È necessario ricordare di sovrascrivere e rimuovere i file di testo chiaro dopo averli guardati.

Un'altra alternativa per tutti voi che condividete un computer e l'accesso sudo (root) è usare la crittografia domestica e lo scambio crittografato.

Ma questo non sarà d'aiuto, se hai effettuato l'accesso contemporaneamente. È un dato di fatto che è necessario riavviare il computer per sbarazzarsi dei file in formato testo chiaro anche con home crittografata.

In generale la sicurezza è molto difficile e un sistema a singolo utente con disco crittografato (LVM con crittografia) sarebbe il modo più semplice per proteggere le cose.

  • Non archiviare dati privati ​​sensibili in un computer condiviso
  • Non archiviare dati privati ​​in un computer che appartiene al tuo datore di lavoro
— sudodus
fonte
3
Un contenitore dm-crypt / LUKS non dovrebbe preoccuparsi di sovrascrivere i file in chiaro (tranne che per i file temporanei e lo scambio di qualsiasi applicazione) o una singola directory crittografata ~ / .Private conecryptfs-mount-private
— Xen2050,
6
Questo non ti protegge nemmeno dai malvagi attacchi da cameriera: l'altro utente sudo può modificare il sistema per indurti a dare loro la tua passphrase. Una domanda del genere dovrebbe essere letta come "sospetto che il mio collega sia una spia russa. Dovrei dargli i diritti di sudo sul mio computer?"
— slitta dal
Che dire di una macchina virtuale con immagine del disco crittografata? blogs.oracle.com/scoter/…
— leftaroundabout
1
Se hai bisogno di privacy, hai bisogno di un singolo sistema utente in altre parole, nessun altro utente, sicuramente nessun altro utente sudo. Ubuntu LVM con sistema di crittografia è vulnerabile a malvagi attacchi da cameriera. Penso comunque che sia meglio delle altre alternative facili, inclusa la casa crittografata. Naturalmente, se lo desideri, puoi avere un disco crittografato, una casa crittografata e un sistema a singolo utente, al fine di rendere le cose più difficili per un intruso, ad esempio secondo questo link, iso.qa.ubuntu.com/qatracker/milestones / 363 / builds / 126342 /…
— sudodus,
Tutto ciò che il nuovo utente root deve fare è installare un rootkit nello spazio del kernel come diamorfina. Non ha nemmeno bisogno di preoccuparsi di confondersi con gli LD_PRELOADhack degli utenti : basta creare un semplice registratore di tasti e lanciarlo su alcuni script Python per eseguire una segmentazione fuzzy dei mezzi K basata sul tempo / raggruppamento della digitazione e un po 'di analisi del testo, e fatto. Ora hai la passphrase per l'utente e puoi probabilmente ottenere i loro dati personali.
— Cloud
8

Una volta che siete in grado di ottenere rooti permessi (ad esempio utilizzando sudo, suecc).
Hai pieno accesso a tutti i file sul sistema.

Pertanto, entrambi gli utenti che dispongono sudodell'autorizzazione e possono rootutilizzarlo sudo bashavranno pieno accesso a tutti i file sul sistema

In base a queste domande e risposte in SE-Security: Potresti essere in grado di modificare SELinux(che non è Ubuntu) per limitare l' rootaccesso:

Se la tua domanda è "posso farlo ora in modo semplice e sicuro?" la risposta è no. Se la tua risposta è "Sono pronto a conoscere SELinux, rimettermi in gioco con la mia distribuzione e sopportare un sacco di cose che non funzionano", la risposta è che è possibile vincolare root molto più della tua installazione media. Detto questo, ciò non ti rende in alcun modo invulnerabile agli exploit - non rende impossibile per un utente eludere questo controllo di accesso aggiuntivo né nel software né fisicamente.

— Yaron
fonte
2
Puoi limitare il root con apparmor e selinux entrambi, tuttavia, qualcuno con accesso root completo o accesso tramite la shell di ripristino o un CD live, con entrambi i sistemi (apparmor o selinux) può cambiarlo indietro.
— Pantera,
1
Anche se usi SELinux o simili per limitare ciò che root può fare direttamente, potrebbero comunque essere in grado di modificare i programmi di utilità eseguiti dagli utenti. E se dovrebbero essere in grado di eseguire eventuali aggiornamenti, avranno bisogno dell'accesso per modificare i file binari sul sistema ...
— ilkkachu,
5

Per chiarire perfettamente ciò che hanno già affermato le altre risposte: quell'altro utente non è solo "root quanto te" (la risposta di Videonauth), ma può anche diventare te (passare al tuo account utente) .

Questo perché con i privilegi di superutente, si può passare a qualsiasi account.

Probabilmente lo sai

sudo su

che è un'opzione per aprire una shell di root se root non ha una password impostata (quindi non puoi semplicemente accedere come root direttamente).

suè l'abbreviazione di "switch user". A quale utente passa? Nessuno è dichiarato, giusto? Ma dalla pagina man, possiamo imparare che:

Richiamato senza un nome utente, per impostazione predefinita su diventa il superutente.

Quindi questo è efficace

sudo su root

se non hai rinominato rootin qualcos'altro.

Se hai appena eseguito su <someuser>, ti verrà richiesta una password. Quindi, se esegui su root, ti viene richiesta la password di root (che non esiste in Ubuntu per impostazione predefinita, quindi non puoi accedere (nota che nessuna password impostata significa che non c'è modo di accedere tramite una password che è diverso dalla password essendo la stringa vuota)). Ma se corri sudo su root, ti viene richiesta la tua password. E sei richiesto solo da sudo. Una volta sudoricevuta la password, esegue il comando ricevuto come parametri con privilegi di superutente. Poiché si è in grado di passare a qualsiasi account quando si dispone dei privilegi di superutente, non è necessaria una richiesta di password.

Quindi eseguendo

sudo su <yourusername>

, l'altro sudoer può accedere come te.

— UTF-8
fonte
+1; Sì, non l'ho menzionato per non aver creato confusione, il campo di protezione di una macchina in modo adeguato è ampio e pieno di pietre sulle quali puoi lottare. Ancora una buona aggiunta a ciò che è già stato dato come risposta.
— Videonauth,
Non sono sicuro, ma non sudo susempre l'impostazione predefinita è UID 0 e GUID 0? Se sì, non dovrebbe importare come hai chiamato 'root'.
— Videonauth,
@Videonauth Hai ragione con la seconda frase nel tuo secondo commento. Questa, tuttavia, è la vera ragione per cui ho incluso la frase che stai criticando. Se rinominate rootin john, sudo suora è equivalente sudo su johne non più a sudo su root.
— UTF-8
3

È possibile limitare i programmi che possono essere eseguiti utilizzando l'escalation dei privilegi sudo modificando il file sudoers ( /etc/sudoers).

Vedi la risposta accettata a questa domanda su Super User per ulteriori dettagli e anche qui su Unix e Linux . Vedi la risposta di slm per un suggerimento su come limitare i privilegi in /etc/sudoers.

Controlla anche la manpagina dei sudoers digitando man sudoerse non dimenticare di provarlo. Ricorda che con l'accesso sudo illimitato un utente può impersonare completamente qualsiasi altro utente. ad esempio, se l'utente foodovesse eseguire il comando

sudo exec su - bar

sarebbero quindi in grado di agire come utenti bar, con tutti i privilegi di quell'utente.

— ammaliatore
fonte
6
Nota che le sudoerslinee specifiche mostrate nelle risposte di slm e mtak non funzionano per dare la possibilità di eseguire alcune azioni e non altre, poiché è banalmente facile usarle per eseguire qualsiasi comando. (Vedi i commenti su ciascuna di quelle risposte per spiegazioni dettagliate del perché.) Questa risposta potrebbe non essere del tutto errata in quanto a volte è possibile consentire agli utenti di utilizzare sudoper eseguire comandi specifici come root senza renderli effettivamente amministratori. Ma è molto difficile farlo bene.
— Eliah Kagan,
@EliahKagan Right. Sarebbe necessario assicurarsi con cura di non consentire loro di raggiungere un meccanismo che consentirebbe loro di eseguire qualsiasi comando. Certo, dipende dal livello di fiducia che riponi nell'altra persona.
1
@EliahKagan Da qui l'esortazione sia a leggere la pagina man sia a testare qualsiasi implementazione. È possibile limitare un utente con privilegio sudo. Tuttavia, come sottolineato, non è una soluzione completamente sicura e un certo livello di fiducia deve essere attribuito agli utenti a cui sono concessi i diritti sudo. Interessante vedere i voti negativi per una risposta che raccomanda l'uso del meccanismo (voci del file sudoers) che è specificamente progettato allo scopo di limitare l'ambito del comando sudo.
— Incantatore,
Penso che non si tratti della raccomandazione di usare un meccanismo integrato, quindi lasciatemi arrivare al punto di quale critica costruttiva potrei darvi per la vostra risposta. 1) Contiene alcuni errori di battitura ed è mal formattato e sembra strano quando lo leggi, che in sé può essere risolto molto facilmente. 2) punti ad altre risposte fornite al di fuori di Ask Ubuntu , qui dovresti prendere le parti essenziali come virgolette e pubblicarle qui, facendo dei tuoi link una parte delle virgolette per puntare alle fonti da cui hai preso quelle. Spero che questo possa aiutare a migliorare la tua risposta.
— Videonauth,
E dal momento che ho finito i personaggi nel mio commento precedente: 3) Potresti andare un po 'più in profondità nella spiegazione, fai notare le avvertenze menzionate da @EliahKagan.
— Videonauth,
0

Le risposte precedenti non si applicano completamente, se contrassegnato encrypt home folderdurante l'installazione di Ubuntu. Ciò garantisce cartelle home crittografate per ogni utente, anche se root non può leggere i dati senza la password corretta dell'utente / proprietario della cartella home. Il tuo collega avrebbe bisogno di cambiare la password per leggere i file, che sarebbe notato.

E, naturalmente, le persone hanno ragione nel dire che condividere macchine con dati preziosi o sensibili su di esso e, in aggiunta, l'accesso alla radice con i colleghi, non è una buona idea.

A seconda del valore di questi dati, suggerirei di richiedere la tua macchina.

— s1mmel
fonte
1
Ciò potrebbe non impedire a un utente root di eseguire una "su -" o una manovra simile non appena la "vittima" è connessa e ha il disco crittografato montato .... potrebbe esserci anche uno script cron o un altro trigger in attesa di quello accadere. Inoltre, un utente root potrebbe facilmente sostituire il file binario che gestisce l'immissione della password per sbloccare la home directory crittografata con una versione che memorizza la password in chiaro e attendere. Eventuali meccanismi di sicurezza che fermano tali attacchi potrebbero ancora essere sfruttati cambiando alcuni file binari che la vittima userà in qualcosa che fa come vuoi tu.
— rackandboneman,
5
Sto scaricando questa risposta come una home directory crittografata aiuta solo se non si è attualmente connessi. Non appena si accede i dati vengono decrittografati e disponibili per l'altro utente con accesso sudo.
— Pantera,
2
Ma perché dovrebbero essere? Anche se gli accessi simultanei non vengono mai eseguiti in remoto (ad es. SSH) o con console virtuali, non è possibile accedere graficamente due utenti contemporaneamente e passare da uno all'altro? Uso Lubuntu (che ha LXDE) e non ho mai effettuato l'accesso graficamente con più utenti contemporaneamente, ma la mia impressione è che ambienti desktop più ricchi di funzionalità lo supportino da alcuni anni e lo abilitino di default. Mi sbaglio al riguardo? In alternativa, i file non sono più decifrati e leggibili da root quando lo schermo è bloccato?
— Eliah Kagan,
2
IRRC le chiavi di crittografia dell'utente sono archiviate apertamente sulla macchina per fornire la crittografia e la decrittografia, quindi una sudo su - <username>che non necessita della password degli altri utenti, normalmente decifrerebbe correttamente la directory degli altri utenti. Ma potrei sbagliarmi qui, ho bisogno di testarlo in una VM e lo farò più tardi. Ad ogni modo, il 99% di tutti i casi si riduce a questo: "Se ho accesso fisico alla tua macchina, sei colpito!".
— Videonauth,
1
Un superutente può modificare la procedura di accesso per registrare i nomi utente e le password che vede. Attendere fino a quando l'altro utente accede e il problema è risolto.
— Stig Hemmer,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.