Il root / superutente può leggere i miei file protetti da lettura?


35

Sull'hosting unix condiviso, se ho un file sensitive-data.txt e rilascio:

chmod 600 sensitive-data.txt

L'utente root può ancora leggere il mio file? In particolare, mi chiedo se è sicuro archiviare la mia password nel file mercgrial hgrc.

AGGIORNARE

Ho deciso di utilizzare l'estensione del portachiavi meccanico poiché era semplicissimo da configurare:

pip install mercurial_keyring

e quindi aggiungi a hgrc:

[extensions]
mercurial_keyring =

Comunque sono ancora interessato alla risposta a questa domanda.

Risposte:


62

Sì, root può:

$ echo Hello you\! > file
$ chmod 600 file
$ ls -l file
-rw------- 1 terdon terdon 11 Feb 27 02:14 file
$ sudo -i
# cat file
Hello you!

In ogni caso, anche se root non è in grado di leggere i tuoi file come root, possono sempre accedere come te senza password:

$ whoami
terdon
$ sudo -i
[sudo] password for terdon: 
# whoami 
root
# su - terdon
$ whoami
terdon

Quindi, rootpuoi passare a qualsiasi altro nome utente usando su(o sudo -iu username) e sarai quindi in grado di fare qualsiasi cosa come se fossi in te.


23

Supponi sempre che root(e qualsiasi altro utente / processo con CAP_DAC_OVERRIDEe CAP_DAC_READ_SEARCH) possa fare tutto a meno che un LSM (SELinux, AppArmor o simile) gli impedisca di farlo.

Ciò significa anche che dovresti presumere che tutti i tuoi tasti possano essere letti. Le password non sono davvero sicure. Se vuoi un livello di sicurezza serio, devi usare un sistema che è completamente controllato da te (e nemmeno usato da nessun altro).


Questo è in realtà il mio problema con le funzionalità in quanto sono attualmente implementate. Dal momento che non specificano obiettivi, è necessario disporre dell'applicazione del tipo che sostituisce le capacità (come SELinux) solo per evitare che ciò accada. Dare a un utente CAP_DAC_OVERRIDEin un solo colpo tutti i privilegi di cui hanno bisogno per scavalcare qualsiasi altro meccanismo di sicurezza sul sistema. CAP_DAC_OVERRIDEè fondamentalmente CAP_DO_WHATEVER_YOU_WANT.
Bratchley

10

Sì, root ha tutti i privilegi per fare qualsiasi cosa

Qui puoi vedere che ho creato un test per il nome della directory, ho toccato un file lonston.txt ed elencato i file

root@system99:/tmp# mkdir test && touch lonston.txt && ls -l
total 4
-rw-r--r-- 1 root root    0 Feb 27 16:35 lonston.txt
drwxr-xr-x 2 root root 4096 Feb 27 16:35 test

Quindi ho modificato l'autorizzazione di file e directory in null null utilizzando 000 ed elencata per vedere l'autorizzazione

root@system99:/tmp# chmod 000 lonston.txt && chmod 000 test && ls -l
total 4
---------- 1 root root    0 Feb 27 16:35 lonston.txt
d--------- 2 root root 4096 Feb 27 16:35 test

Quindi anche io posso scrivere sul file e leggere il file usando cat

root@system99:/tmp# echo "Yes root have all Privileges than other user's, let we see the permission of user's too" > lonston.txt 

root@system99:/tmp# cat lonston.txt 
Yes root have all Privilages than other user's, let we see the permission of user's too

Anche io posso entrare nella directory che ha l'autorizzazione d --------- (null) 000, anche root non ha permessi di lettura o scrittura.

root@system99:/tmp# cd test/
root@system99:/tmp/test# pwd
/tmp/test

Anche io posso creare i file e le cartelle dopo il cambio di autorizzazione da qualsiasi fosse

root@system99:/tmp/test# touch /tmp/test/lonston/testdir/babin.txt

root@system99:/tmp/test# ls -l /tmp/test/lonston/testdir/
total 0
-rw-r--r-- 1 root root 0 Feb 27 16:39 babin.txt

Ora qui possiamo vedere Autorizzazione con 400

root@system99:/tmp/test# chmod 400 babin.txt

Elenco per vedere il permesso del file

root@system99:/tmp/test# ls -l
total 8
-r-------- 1 root root   34 Feb 27 16:42 babin.txt
drwxr-xr-x 3 root root 4096 Feb 27 16:38 lonston

Usando vim im ho aggiunto 1 riga al file babin.txt

root@system99:/tmp/test# vim babin.txt

Ma mentre in modalità vim ci noterà W10: Avviso: modifica di un file di sola lettura Ma è comunque scrivibile

Ora possiamo catalogare il file per l'output

root@system99:/tmp/test# cat babin.txt 
hi this is the write persmission 
this is added while the file have 400 permission

Quindi ho effettuato il logout da utente root a utente normale ed ho elencato il file con permessi null anche in root

root@system99:/tmp# exit
exit

Passare alla directory / tmp

sysadmin@system99:~$ cd /tmp/
sysadmin@system99:/tmp$ ls -l
total 8
---------- 1 root root   88 Feb 27 16:36 lonston.txt
d--------- 2 root root 4096 Feb 27 16:35 test

Ma durante la lettura del file da un utente normale non possiamo

sysadmin@system99:/tmp$ cat lonston.txt 
cat: lonston.txt: Permission denied

sysadmin@system99:/tmp$ cd test/
cat: test/: Permission denied

Questo è tutto, spero che tu abbia il potere di utente root

Se sei in Utente normale, se hai bisogno del privilegio di root dobbiamo usare sudo, chiederà sudo password

esempio :

sysadmin@system99:/tmp$ sudo cat lonston.txt 
[sudo] password for sysadmin: 
Yes root have all Privilages than other user's, let we see the permission of user's too

L'utente del Sudo ha una collaborazione con il gruppo dell'utente root, quindi ciò che sudo ha il privilegio di root.

Per saperne di più su sudo

# man sudoers

Qui possiamo vedere che hanno definito come l'utente normale può avere i diritti di Sudo Solo meno righe che ho citato qui.

sysadmin@system99:/tmp$ sudo cat /etc/sudoers

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Totalmente possiamo leggere o modificare o eliminare i file anche root Non ha i permessi di lettura.


2
Perché questa risposta ha così pochi voti? Copre quasi tutti i casi che possono verificarsi con esempi.
Foo Bar,

8

In Unix tradizionale, root è onnipotente. In particolare, root può leggere qualsiasi file e persino curiosare su ciò che i tuoi programmi stanno facendo internamente. Se i dati sono veramente sensibili, tieni solo le copie crittografate (considera ad esempio GNU Privacy Guard per questo, ma leggi attentamente la sua documentazione prima) e non decodificarli mai su una macchina che non è sotto il tuo controllo completo.

(La paranoia è meravigliosa, non ce n'è mai abbastanza ;-)

Seriamente, rifletti attentamente sui costi che la perdita dei dati potrebbe causare e quindi su quanto sarai disposto a pagare per la sicurezza. La sicurezza perfetta è impossibile, per ottenere un po 'più di sicurezza il costo inizia ad aumentare rapidamente. Ma fai attenzione a non cadere nella trappola di una misura costosa che in realtà non aumenta la sicurezza ...


3

Si dovrebbe anche presumere che chiunque abbia l'opportunità di trovarsi nella stessa stanza dell'hardware può leggere o scrivere tutto ciò che desidera. Se sono molto pazienti, possono finalmente comprendere i dati crittografati. Non hanno bisogno dei metodi del canale laterale se possono sostituire il software di crittografia.


2

Sì, il root può leggere il file protetto anche quando il proprietario non può (mentre il proprietario ovviamente può rimuovere la protezione e quindi leggere il contenuto):

echo "123" > abc.txt
chmod 000 abc.txt
cat abc.txt

cat: abc.txt: autorizzazione negata

su
cat abc.txt

123

Tuttavia, durante l'installazione normale, il root non può accedere ai file protetti sui filesystem remoti come NFS ("root squash").


+1 per menzionare la radice di NFS. Tuttavia, fino a quando root può fare richiesta all'utente che possiede la directory montata su NFS, root squash non protegge ancora.
Jenny D,

2

Per impedire a root o a chiunque di leggere i tuoi file, devi crittografarli. La crittografia dei file è un'opzione molto comoda da esaminare se si desidera evitare di dover gestire manipolazioni complesse del file system.

Opzioni di crittografia:

  1. Crittografa i file ordinari e impedisce a tutti tranne te stesso di poterli visualizzare
  2. Crittografa gli script della shell e rende eseguibili le versioni crittografate, ma impedisce anche a tutti di modificarle o visualizzarle

Se scegli l'opzione 1, ecco un modo per crittografare i tuoi file:

cat (your-file) | openssl aes-128-cbc -a -salt -k "(specify-a-password)" > (your-file).enc

Per decrittografare il file sopra, esegui un comando come questo:

cat (your-file).enc | openssl aes-128-cbc -a -d -salt -k "(specify-the-password)" > (your-file).dec

- Potresti voler inserire quanto sopra in uno script in modo che non venga visualizzato nella tua cronologia. Oppure, puoi semplicemente rimuovere il parametro " -k ", che chiederà a openssl di chiederti una password.

Se scegli l'opzione 2, copia e incolla semplicemente il tuo script sul seguente sito:

http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm

Al momento dell'invio del tuo script a quel sito, verrà creato immediatamente un file zip per te. Copia il collegamento nel file zip, quindi vai alla casella UNIX ed esegui questi passaggi:

  1. wget link-to-the-zip-file
  2. decomprimere il file zip appena scaricato
  3. cd / tmp / KingLazySHIELD
  4. ./install.sh / var / tmp / KINGLAZY / SHIELDX- (your-script-name) / home / (your-username) -force

Una volta completati i passaggi precedenti, è possibile eseguire il proprio script crittografato da qualsiasi posizione in cui è stato specificato per averlo installato nel passaggio 4 .... ie / home / (nome utente) / (script crittografato). sh

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.