Czy root / administrator może odczytać moje pliki chronione przed odczytem?

Na dzielonym hostingu unixowym, jeśli mam plik wrażliwy data.txt i wystawiam:

chmod 600 sensitive-data.txt

Czy użytkownik root może nadal czytać mój plik? W szczególności zastanawiam się, czy bezpiecznie jest przechowywać moje hasło w mercurial hgrc.

AKTUALIZACJA

Postanowiłem skorzystać z rozszerzenia brelok do kluczy, ponieważ jego konfiguracja była bardzo łatwa:

pip install mercurial_keyring

a następnie dodaj do hgrc:

[extensions]
mercurial_keyring =

Jednak nadal jestem zainteresowany odpowiedzią na to pytanie.

Tak, root może:

$ 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!

W każdym razie, nawet jeśli root nie może odczytać twoich plików jako root, zawsze mogą się zalogować jako użytkownik bez hasła:

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

Tak więc, rootmożna zmienić na dowolną inną nazwę użytkownika za pomocą su(lub sudo -iu username), a następnie będzie w stanie zrobić wszystko tak, jakby to byłeś Ty.

Zawsze zakładaj, że root(i każdy inny użytkownik / proces za pomocą CAP_DAC_OVERRIDEi CAP_DAC_READ_SEARCH) może zrobić wszystko, chyba że LSM (SELinux, AppArmor lub podobny) mu to uniemożliwi.

Oznacza to również, że powinieneś założyć, że wszystkie twoje naciśnięcia klawiszy można odczytać. Hasła nie są naprawdę bezpieczne. Jeśli chcesz poważnego poziomu bezpieczeństwa, musisz użyć systemu całkowicie kontrolowanego przez ciebie (a nawet nieużywanego przez nikogo innego).

Tak, root ma wszystkie uprawnienia do robienia czegokolwiek

Tutaj możesz zobaczyć, że utworzyłem test nazwy katalogu, dotknąłem pliku lonston.txt i wymieniłem pliki

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

Następnie zmieniłem uprawnienia do pliku i katalogu na uprawnienie zerowe przy użyciu 000 i wymieniłem je, aby zobaczyć to uprawnienie

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

Wtedy nawet mogę zapisać do pliku i odczytać plik za pomocą 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

Nawet ja mogę dostać się do katalogu, który ma d --------- (null) 000 uprawnień, nawet root nie ma uprawnień do odczytu ani zapisu.

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

Nawet ja mogę tworzyć pliki i foldery po zmianie uprawnień z dowolnego z nich

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

Teraz tutaj możemy zobaczyć Pozwolenie z 400

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

Lista, aby zobaczyć uprawnienia do pliku

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

Używając vim im, dodałem 1 linię do pliku babin.txt

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

Ale w trybie vim zauważy nas W10: Ostrzeżenie: Zmiana pliku tylko do odczytu Ale nadal można go zapisać

Teraz możemy cat plik do wyjścia

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

Następnie wylogowałem się z użytkownika root do zwykłego użytkownika i wymieniłem plik z uprawnieniem zerowym, co również w katalogu głównym

root@system99:/tmp# exit
exit

Przejdź do katalogu / 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

Ale podczas czytania pliku od zwykłego użytkownika nie możemy

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

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

To wszystko, mam nadzieję, że masz moc użytkownika root

Jeśli jesteś w trybie zwykłego użytkownika, jeśli potrzebujesz uprawnień roota, musimy użyć sudo, poprosi o hasło sudo

przykład:

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

Użytkownik Sudo ma współpracę z grupą użytkowników root, więc jakie sudo mają uprawnienia roota.

Aby dowiedzieć się więcej o sudo

# man sudoers

Tutaj widzimy, że zdefiniowali, że zwykły użytkownik może mieć prawa do Sudo. Tylko kilka linii, o których tu wspomniałem.

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

Całkowicie możemy czytać, edytować lub usuwać pliki nawet root Nie ma uprawnień do odczytu.

W tradycyjnym Uniksie root jest wszechmocny. W szczególności root może odczytać dowolny plik, a nawet szpiegować to, co robią twoje programy wewnętrznie. Jeśli dane są naprawdę wrażliwe, przechowuj tylko zaszyfrowane kopie (rozważ np. Ochronę prywatności GNU , ale przeczytaj dokładnie dokumentację wcześniej) i nigdy nie odszyfruj ich na komputerze, który nie jest pod Twoją pełną kontrolą.

(Paranoja jest cudowna, nigdy jej nie ma dość ;-)

Poważnie, zastanów się dokładnie, jakie koszty może spowodować wyciek danych, a tym samym, ile będziesz gotów zapłacić za bezpieczeństwo. Doskonałe bezpieczeństwo jest niemożliwe, aby uzyskać nieco większe bezpieczeństwo, koszt zaczyna gwałtownie rosnąć. Uważaj jednak, aby nie wpaść w pułapkę kosztownego środka, który tak naprawdę nie zwiększa bezpieczeństwa ...

Należy również założyć, że każdy, kto może mieć możliwość przebywania w tym samym pomieszczeniu, w którym znajduje się sprzęt, może czytać lub pisać, co tylko zechce. Jeśli są bardzo cierpliwi, mogą w końcu zrozumieć zaszyfrowane dane. Nie potrzebują metod bocznego kanału, jeśli mogą zastąpić oprogramowanie szyfrujące.

Tak, root może odczytać chroniony plik, nawet jeśli właściciel nie może (podczas gdy właściciel oczywiście może usunąć ochronę, a następnie odczytać zawartość):

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

cat: abc.txt: Odmowa dostępu

su
cat abc.txt

123

Jednak w normalnej konfiguracji root nie ma dostępu do chronionych plików w zdalnych systemach plików, takich jak NFS („root squash”).

Aby uniemożliwić rootowi lub komukolwiek odczytanie plików, musisz je zaszyfrować. Szyfrowanie plików jest bardzo wygodną opcją, jeśli chcesz uniknąć skomplikowanych operacji na systemie plików.

Opcje szyfrowania:

1. Zaszyfruj zwykłe pliki i uniemożliwić wszystkim osobom oprócz Ciebie ich przeglądanie
2. Zaszyfruj skrypty powłoki i spraw, aby zaszyfrowane wersje były wykonalne, ale również uniemożliwić wszystkim ich modyfikowanie lub przeglądanie

Jeśli wybierzesz opcję 1, oto sposób na zaszyfrowanie plików:

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

Aby odszyfrować powyższy plik, uruchom następujące polecenie:

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

- Możesz umieścić powyższe w skrypcie, aby nie pojawił się w Twojej historii. Możesz też po prostu usunąć parametr „ -k ”, który poprosi openssl o podanie hasła.

Jeśli wybierzesz opcję 2, po prostu skopiuj i wklej skrypt do następującej witryny:

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

Po przesłaniu skryptu do tej witryny natychmiast zostanie utworzony plik zip. Skopiuj link do pliku zip, a następnie przejdź do pola UNIX i wykonaj następujące czynności:

1. wget link-to-the-zip-file
2. rozpakuj nowo pobrany plik zip
3. cd / tmp / KingLazySHIELD
4. ./install.sh / var / tmp / KINGLAZY / SHIELDX- (twoja nazwa skryptu) / home / (twoja nazwa użytkownika) -force

Po wykonaniu powyższych kroków możesz po prostu uruchomić zaszyfrowany skrypt z dowolnego miejsca, w którym został określony, aby zainstalować go w kroku 4 .... tj. / Home / (twoja-nazwa użytkownika) / (twój-zaszyfrowany-skrypt). sh