Est-ce que root / superutilisateur peut lire mes fichiers protégés en lecture?

Sur l'hébergement mutualisé Unix, 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 prudent de stocker mon mot de passe dans le fichier mercurial hgrc.

MISE À JOUR

Nous avons décidé d'utiliser l'extension de porte-clés mecurial, car elle était très facile à configurer:

pip install mercurial_keyring

puis ajoutez à hgrc:

[extensions]
mercurial_keyring =

Cependant, la réponse à cette question m'intéresse toujours.

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 ne peut pas 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

Donc, vous rootpouvez changer d’utilisateur à l’aide de su(ou sudo -iu username) et vous pourrez alors faire tout ce que vous voulez.

Supposez toujours que root(et tout autre utilisateur / processus avec CAP_DAC_OVERRIDEet CAP_DAC_READ_SEARCH) peut tout faire sauf si un LSM (SELinux, AppArmor ou similaire) l’empêche de le faire.

Cela signifie également que vous devez supposer que toutes vos frappes au clavier peuvent être lues. Les mots de passe ne sont pas vraiment sécuritaires. Si vous souhaitez un niveau de sécurité élevé, vous devez utiliser un système entièrement contrôlé par vous (et même utilisé par personne 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, 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é la permission du fichier et du répertoire en une permission nulle en utilisant 000 et listée pour voir la permission

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 le lire à l'aide de chat

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 si 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 je peux créer les fichiers et les dossiers après le changement d'autorisation 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, nous pouvons voir la permission avec 400

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

Liste pour voir l'autorisation du 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: Avertissement: Changer un fichier en lecture seule, mais cela reste inscriptible.

Nous pouvons maintenant lire le fichier en cat.

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 en utilisateur normal et j'ai répertorié le fichier avec une permission nulle, ce qui en 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

Ça y est, j'espère que vous avez le pouvoir d'utilisateur root

Si vous êtes utilisateur normal, si vous avez besoin du privilège root, nous devons utiliser sudo, il vous demandera 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 de l’utilisateur root, donc quel sudo a le privilège root.

En savoir plus sur sudo

# man sudoers

Nous pouvons voir ici qu’ils ont été définis comme étant l’utilisateur normal pouvant avoir des droits Sudo. 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

Totalement, nous pouvons lire ou éditer ou Supprimer les fichiers même racine N'a pas la permission de lire.

Dans Unix traditionnel, root est tout-puissant. En particulier, root peut lire n’importe quel fichier et même surveiller ce que vos programmes font en interne. Si les données sont vraiment sensibles, conservez uniquement des copies chiffrées (pensez par exemple à GNU Privacy Guard , mais lisez attentivement sa documentation auparavant), et ne le déchiffrez jamais sur une machine qui n’est pas entièrement sous votre contrôle.

(La paranoïa est magnifique, il n'y en a jamais assez ;-)

Sérieusement, réfléchissez bien aux coûts engendrés par la fuite des données et déterminez donc le montant que vous êtes 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. Attention toutefois à ne pas tomber dans le piège d'une mesure coûteuse qui n'augmente pas vraiment la sécurité ...

Il faut également supposer que toute personne pouvant avoir la possibilité de se trouver dans la même pièce que le matériel informatique peut lire ou écrire tout ce qu’ils veulent. S'ils sont très patients, ils peuvent éventuellement comprendre des données cryptées. Ils n'ont pas besoin de méthodes de canal latéral s'ils peuvent remplacer le logiciel de chiffrement.

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: permission 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 tels que NFS ("root squash").

Afin d'empêcher root ou tout autre utilisateur de pouvoir lire vos fichiers, vous devez les chiffrer. Le chiffrement de fichier est une option très pratique à examiner si vous souhaitez éviter de devoir traiter avec des manipulations complexes du système de fichiers.

Options de cryptage:

1. Cryptez des fichiers ordinaires et empêchez tout le monde à part de pouvoir les visualiser
2. Cryptez les scripts shell et rendez les versions cryptées exécutables, mais empêchez tout le monde de les modifier ou de les visualiser

Si vous choisissez l'option 1, voici une façon de chiffrer vos fichiers:

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

Pour déchiffrer 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 le texte ci-dessus dans un script afin qu'il n'apparaisse pas dans votre historique. Ou bien, vous pouvez simplement supprimer le paramètre " -k ", ce 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 sur ce site, un fichier zip sera instantanément créé pour vous. Copiez le lien dans le fichier zip, puis allez dans votre zone UNIX et procédez comme suit:

1. lien wget vers le fichier zip
2. Décompressez le fichier zip récemment téléchargé
3. cd / tmp / KingLazySHIELD
4. ./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 simplement exécuter votre script chiffré à partir de l’endroit où vous le spécifiez pour l’installer à l’étape 4 ... c.-à-d. / Home / (votre nom d’utilisateur) / (votre script chiffré). sh