Le superutilisateur / root peut-il lire mes fichiers protégés en lecture?
Sur l'hébergement Unix partagé, si j'ai un fichier sensitive-data.txt et que j'émets:
chmod 600 sensitive-data.txt
L'utilisateur root peut-il toujours lire mon fichier? Plus précisément, je me demande s'il est sûr de stocker mon mot de passe dans le fichier Mercurial hgrc.
MISE À JOUR
Décidé d'utiliser l'extension de porte-clés mécanique car elle était super facile à configurer:
pip install Mercurial_keyring
puis ajoutez à hgrc:
[extensions]
Mercurial_keyring =
Cependant, je suis toujours intéressé par la réponse à cette question.
Oui, root peut:
$ 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!
Dans tous les cas, même si root n'a pas pu lire vos fichiers en tant que root, ils peuvent toujours se connecter en tant que vous sans mot de passe:
$ whoami
terdon
$ Sudo -i
[Sudo] password for terdon:
# whoami
root
# su - terdon
$ whoami
terdon
Ainsi, root peut être remplacé par n'importe quel autre nom d'utilisateur à l'aide de su (ou Sudo -iu username) et pourra alors tout faire comme si c'était vous.
Supposez toujours que root (et tout autre utilisateur/processus avec CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH) peut faire tout à moins qu'un LSM (SELinux, AppArmor ou similaire) ne l'en empêche.
Cela signifie également que vous devez supposer que toutes vos frappes peuvent être lues. Les mots de passe ne sont pas vraiment sûrs. Si vous voulez un niveau de sécurité sérieux, vous devez utiliser un système entièrement contrôlé par vous (et même pas utilisé par quelqu'un d'autre).
Oui root a tous les privilèges pour faire quoi que ce soit
Ici, vous pouvez voir que j'ai créé un test de nom de répertoire et touché un fichier lonston.txt et répertorié les fichiers
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
Ensuite, j'ai changé l'autorisation du fichier et du répertoire en autorisation nulle en utilisant 000 et répertorié pour voir l'autorisation
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
Ensuite, même je peux écrire dans le fichier et lire le fichier en utilisant 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
Même moi, je peux entrer dans le répertoire qui a la permission d --------- (null) 000, même la racine n'a pas de permission de lecture ou d'écriture.
root@system99:/tmp# cd test/
root@system99:/tmp/test# pwd
/tmp/test
Même moi, je peux créer les fichiers et les dossiers après le changement de permission de tout
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
Maintenant, ici, nous pouvons voir l'autorisation avec 400
root@system99:/tmp/test# chmod 400 babin.txt
Liste pour voir l'autorisation de fichier
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
En utilisant vim im, j'ai ajouté 1 ligne au fichier babin.txt
root@system99:/tmp/test# vim babin.txt
Mais en mode vim, il nous remarquera W10: Attention: Changer un fichier en lecture seule Mais il est toujours accessible en écriture
Maintenant, nous pouvons cat le fichier pour la sortie
root@system99:/tmp/test# cat babin.txt
hi this is the write persmission
this is added while the file have 400 permission
Ensuite, je me suis déconnecté de l'utilisateur root vers l'utilisateur normal et j'ai répertorié le fichier ayant une permisson nulle dans root aussi
root@system99:/tmp# exit
exit
Accédez au répertoire/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
Mais en lisant le fichier d'un utilisateur normal, nous ne pouvons pas
sysadmin@system99:/tmp$ cat lonston.txt
cat: lonston.txt: Permission denied
sysadmin@system99:/tmp$ cd test/
cat: test/: Permission denied
Voilà, j'espère que vous avez le pouvoir de l'utilisateur root
Si vous en utilisateur normal, si vous avez besoin de privilèges root, nous devons utiliser Sudo, il vous demandera le mot de passe Sudo
exemple :
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
Les utilisateurs de Sudo ont une collaboration avec le groupe d'utilisateurs root, de sorte que Sudo a le privilège root.
En savoir plus sur Sudo
# man sudoers
Ici, nous pouvons voir qu'ils ont défini que l'utilisateur normal peut avoir des droits Sudo. Seulement moins de lignes que j'ai mentionnées ici.
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
Au total, nous pouvons lire ou modifier ou supprimer les fichiers même root N'a pas l'autorisation de lecture.
Dans Unix traditionnel, root est tout-puissant. En particulier, root peut lire n'importe quel fichier et même regarder ce que font vos programmes en interne. Si les données sont vraiment sensibles, ne gardez que des copies chiffrées (pensez par exemple GNU Privacy guard pour cela, mais lisez sa documentation soigneusement avant), et jamais le déchiffrer sur une machine qui n'est pas sous votre contrôle total.
(La paranoïa est merveilleuse, il n'y en a jamais assez ;-)
Sérieusement, réfléchissez bien aux coûts que la fuite des données pourrait entraîner, et donc combien vous serez prêt à payer pour la sécurité. Une sécurité parfaite est impossible, pour obtenir un peu plus de sécurité, le coût commence à augmenter rapidement. Mais attention à ne pas tomber dans le piège d'une mesure coûteuse qui n'augmente vraiment pas la sécurité ...
Il faut également supposer que toute personne qui pourrait avoir la possibilité de se trouver dans la même pièce que le matériel peut lire ou écrire tout ce qu'elle veut. S'ils sont très patients, ils peuvent éventuellement comprendre les données chiffrées. Ils n'ont pas besoin de méthodes de canal latéral s'ils peuvent remplacer le logiciel de cryptage.
Afin d'empêcher root ou n'importe qui de pouvoir lire vos fichiers, vous devez les crypter. Le chiffrement de fichiers est une option très pratique à examiner si vous souhaitez éviter d'avoir à faire face à des manipulations complexes du système de fichiers.
Options de cryptage:
- Cryptez les fichiers ordinaires et empêchez tout le monde sauf vous de les voir
- Crypter les scripts shell et rendre les versions cryptées exécutables, mais aussi empêcher tout le monde de pouvoir les modifier ou les afficher
Si vous choisissez l'option 1, voici un moyen de crypter vos fichiers:
cat (your-file) | openssl aes-128-cbc -a -salt -k "(specify-a-password)" > (your-file).enc
Pour décrypter le fichier ci-dessus, vous exécutez une commande comme celle-ci:
cat (your-file).enc | openssl aes-128-cbc -a -d -salt -k "(specify-the-password)" > (your-file).dec
- Vous voudrez peut-être mettre ce qui précède dans un script afin qu'il n'apparaisse pas dans votre historique. Ou, vous pouvez simplement supprimer le paramètre " - k ", qui invitera openssl à vous demander un mot de passe.
Si vous choisissez l'option 2, copiez et collez simplement votre script sur le site suivant:
http://www.kinglazy.com/Shell-script-encryption-kinglazy-shieldx.htm
Lors de la soumission de votre script à ce site, un fichier Zip sera instantanément créé pour vous. Copiez le lien vers le fichier Zip, puis accédez à votre boîte UNIX et procédez comme suit:
- wget lien vers le fichier Zip
- décompressez le fichier Zip nouvellement téléchargé
- cd/tmp/KingLazySHIELD
- ./install.sh/var/tmp/KINGLAZY/SHIELDX- (votre-nom-de-script)/home/(votre-nom-d'utilisateur) -force
Une fois que vous avez terminé les étapes précédentes, vous pouvez alors simplement exécuter votre script crypté à partir de l'endroit où vous l'avez spécifié pour l'installer à l'étape 4 ... c'est-à-dire. /home/(your-username)/(your-encrypted-script).sh
Oui, la racine peut lire le fichier protégé même lorsque le propriétaire ne le peut pas (alors que le propriétaire peut évidemment supprimer la protection puis lire le contenu):
echo "123" > abc.txt
chmod 000 abc.txt
cat abc.txt
cat: abc.txt: autorisation refusée
su
cat abc.txt
123
Cependant, dans une configuration normale, la racine ne peut pas accéder aux fichiers protégés sur les systèmes de fichiers distants comme NFS ("root squash").