Question Linux - Existe-t-il un moyen d'empêcher / de protéger un fichier d'être supprimé, même par root?


J'ai un fichier très important utilisé par une application sur mon lieu de travail, je dois m'assurer qu'il ne soit pas supprimé, comment puis-je le faire?


86
2017-12-02 16:02


origine


Faites une sauvegarde pour pouvoir la restaurer ... En dehors de cela, chattr +i pourrait aider mais rendra le fichier en lecture seule aussi (et peut être écrasé avec chattr -i), vous pouvez aussi essayer de le protéger avec SELInux etc. - Sven♦
Est-ce que root peut créer un processus que même root ne peut pas tuer? - Mark Gabriel
@ MarkGabriel Oui. Une fourchette bombe. :) - reirab
Dieu, Root, quelle est la différence? - Dan Neely
L’administrateur matériel peut venir retirer le disque, le déchiqueter, brûler les restes et les nourrir à des hoghs. Ou mieux, certains programmeurs C (++) peuvent induire des démons nasaux. Tout ce qui est important pour vous, sauvegardez-le. Deux fois. - Pavel


Réponses:


Oui, vous pouvez modifier les attributs du fichier en lecture seule.

La commande est:

chattr +i filename

Et pour le désactiver:

chattr -i filename

De man chattr:

Un fichier avec le i Cet attribut ne peut pas être modifié: il ne peut être ni supprimé ni renommé, aucun lien ne peut être créé avec ce fichier et aucune donnée ne peut être écrite dans le fichier. Seul le superutilisateur ou un processus possédant le CAP_LINUX_IMMUTABLE la capacité peut définir ou effacer cet attribut.


127
2017-12-02 16:04



Pour les intéressés, l'équivalent en bsd est chflags schg - Andrew Domaszek
Notez qu'un utilisateur avec un accès root peut supprimer cet indicateur, puis supprimer le fichier. Il est peu probable que cela se produise par accident, mais cela ne préjuge pas de la suppression intentionnelle. - Grant
@Grant, pas si le Niveau de sécurité est placé assez haut. Le processus de démarrage définit le securelevel sur 2 avant l'activation du réseau. La réinitialisation de l'indicateur nécessite donc un accès à la machine locale (mais cela signifie que les fichiers utilisés dans le processus de démarrage avant cette heure doivent également être immuables). - Simon Richter
@Grant Si vous voulez aller trop loin, vous ne pouvez pas empêcher la suppression de la partition, l'insertion du disque dans un four ou la dégradation des protons dans 10 ^ 30 ans ... - Hagen von Eitzen
Homme d'Itai Ganot J'aurais aimé le lire il y a 4 jours. J'étais une question dans un examen que j'ai passé = / - vfbsilva


Gravez-le sur un CD. Placez le CD dans un lecteur de CD-ROM et accédez-y à partir de là.


80
2017-12-03 15:18



+1 pour sortir des sentiers battus. Et, autant que je sache, il a également été utilisé auparavant dans certaines circonstances (lecteur de CD-ROM avec boîte noire contenant le CD expédié à sa destination). Cela peut ne pas être approprié si quelqu'un est capable de déconnecter le lecteur, de toute façon. - Alex Mazzariol
BAISER. J'aime cela! +1 - MonkeyZeus
Je pense que c'est la bonne réponse à cette question. Changer l'attribut de fichier (chattr -i) ne peut empêcher des actions malveillantes. - Bruno von Paris
De nos jours, une carte SD pleine taille dans un lecteur de carte intégré peut constituer une meilleure solution: consommation d'énergie réduite, accès plus rapide dans de nombreux cas et plus durable en utilisation sans écriture. - Chris H
@ jpmc26 d'où lecteur de CD-ROM. Ceux-ci sont en lecture / seulement. - Thorbjørn Ravn Andersen


  1. Créez une image du système de fichiers.
  2. Montez l'image.
  3. Copiez le fichier dans l'image montée.
  4. Démontez l'image et remontez-la en lecture seule.
  5. Maintenant, vous ne pouvez pas le supprimer.

Exemple:

# dd if=/dev/zero of=readonly.img bs=1024 count=1024
# mkfs.ext2 readonly.img
# mkdir readonlyfolder
# mount readonly.img readonlyfolder/
# echo "can't delete this" > readonlyfolder/permanent.txt
# umount readonlyfolder
# mount -o ro readonly.img readonlyfolder
# cat readonlyfolder/permanent.txt 
can't delete this
# rm readonlyfolder/permanent.txt 
rm: cannot remove `readonlyfolder/permanent.txt': Read-only file system

28
2017-12-03 20:33



mount -o remount,rw readonlyfolder/ && rm readonlyfolder/permanent.txt - Kaz Wolfe
Prenant cela un peu plus loin, vous pouvez utiliser squashfs ou cramfs qui sont compressés et en lecture seule. Il faut un outil spécial pour construire le système de fichiers. - Zan Lynx


Vous devez également créer plusieurs liens physiques vers le fichier. Ceux-ci doivent être situés à différents endroits auxquels les utilisateurs réguliers ne peuvent pas accéder.

Ainsi, même s'ils parviennent à outrepasser votre protection chattr, les données restent et vous pouvez facilement les restaurer à l'endroit où votre application le recherche.


6
2017-12-03 05:15



Les liens physiques ne protégeront pas le contenu du fichier. - 200_success
Cependant, ils fourniront une protection supplémentaire contre la SUPPRESSION, qui était la question initiale. - barbecue
@barbecue Si le fichier n'est pas lié au nom qu'une application recherche, le contenu du fichier n'a pas d'importance, il peut exister sous un autre nom. Pour tout ce qui cherche le fichier avec le nom attendu, le fichier a toujours été supprimé. - α CVn


Linux a soi-disant bind-mount option qui est assez puissant et fonctionnalité utile à savoir:

%  cd $TMP && mkdir usebindmountluke && cd usebindmountluke
%  echo usebindmountluke > preciousfile
%  sudo mount -B preciousfile preciousfile
%  sudo mount -oremount,ro preciousfile
%  echo sowhat > preciousfile
zsh: read-only file system: preciousfile
%  rm preciousfile
rm: cannot remove ‘preciousfile’: Read-only file system

- ce qui est fait ici est un fichier de montage lié à lui-même (oui, vous pouvez le faire sous Linux), puis il est remonté en mode R / O. Bien sûr, cela peut aussi être fait dans le répertoire.


6
2017-12-06 23:40





D'autres ont répondu à votre question comme vous l'avez posée. Comme @Sven l'a mentionné dans un commentaire, la solution générale à la question "Comment puis-je m'assurer de ne jamais perdre un fichier?" est de créer une sauvegarde du fichier. Faites une copie du fichier et stockez-le à plusieurs endroits. En outre, si le fichier est extrêmement important et que votre société dispose d'une politique de sauvegarde des données importantes avec un service de sauvegarde, vous pouvez éventuellement inclure ce fichier dans le service.


5
2017-12-03 07:02



Bien sûr, le fichier est sauvegardé régulièrement, je voulais simplement une autre couche de protection contre les utilisateurs qui travaillent parfois sur la boîte avec les autorisations d’utilisateur root.


Dans un commentaire à la réponse de Kevin, Jerry mentionne:

Bien sûr, le fichier est sauvegardé régulièrement, je voulais simplement une autre couche de protection contre les utilisateurs qui travaillent parfois sur la boîte avec les autorisations d’utilisateur root. -

Je vais supposer que vous ne pouvez pas changer cette pratique, car c'est une très, très mauvaise idée.

Toutes les suggestions relatives à l'utilisation d'un périphérique en lecture seule ont le même problème: cela en fait un PITA pour vous permettre d'apporter des modifications légitimes lorsque vous en avez besoin. Dans le cas d'un lecteur verrouillable, tel qu'une carte SD, vous vous retrouvez soudainement vulnérable lorsque vous le déverrouillez pour effectuer vos modifications.

Ce que je recommanderais plutôt, c'est de configurer une autre machine en tant que serveur NFS et de partager le répertoire avec les fichiers importants sur la ou les machines sur lesquelles les utilisateurs disposent de la racine. Partagez le montage en lecture seule, de sorte que les machines avec des utilisateurs auxquels vous ne faites pas confiance ne puissent apporter aucune modification. Lorsque vous devez légitimement apporter des modifications, vous pouvez vous connecter au serveur NFS et y apporter nos modifications.

Nous l'utilisons pour nos serveurs Web, de sorte qu'un exploit réussi contre le serveur Web ne sera pas en mesure d'insérer ou de modifier les fichiers que le serveur servirait ensuite ou de modifier la configuration.

Notez que cela peut être évité de la même manière que tous ceux liés aux points de montage:

  • Faire une copie du répertoire protégé
  • Démonter le répertoire
  • Déplacez la copie à la place du montage ou créez un lien symbolique vers ce dernier si l'espace disponible sur ce montage est insuffisant.

3
2017-12-07 13:04



Pourquoi est-ce une "très, très mauvaise idée" de sauvegarder régulièrement un fichier important et de s’efforcer de protéger le fichier original contre toute suppression accidentelle? Dans la question initiale du PO, et d'après le commentaire du PO sur la réponse que vous avez mentionnée, il est clair qu'il ne s'agit pas d'une activité malveillante, mais d'une activité accidentelle / incompétente. - Craig
@Craig: c'est une mauvaise idée d'avoir beaucoup d'utilisateurs avec root, surtout s'ils ne font pas confiance à eux pour ne pas jouer avec les fichiers critiques. - Joe H.
Ah… bien sûr que ça l'est. :-) Mais ce n'était pas le noeud de la question du PO. Le PO a affirmé qu'il y avait sont les utilisateurs avec un accès root qui doivent être protégés contre la suppression accidentelle d'un fichier. - Craig
@Craig: ce n'est peut-être pas le noeud de la question, mais est le noeud du problème (problème XY?) ... mais je n'ai aucune idée de ce qu'ils font en tant que root, donc s'ils pouvaient utiliser les privilèges setuid et / ou sudo limités. Et vous devriez relire la question, car je ne vois aucune mention de Jerry selon laquelle il essaie seulement de se protéger contre un renvoi involontaire ("je dois m'assurer que ce n'est pas supprimé du tout"), et il n'a donné qu'un suivi: voir (qui a déclenché ma réponse). - Joe H.
Voir la réponse du PO à cette réponse - Craig


Sous Linux, le immuable L’indicateur n’est supporté que par certains types de système de fichiers (la plupart des systèmes natifs comme ext4, xfs, btrfs...)

Sur les systèmes de fichiers où il n'est pas pris en charge, une autre option consiste à monter le fichier sur lui-même en mode lecture seule. Cela doit être fait en deux étapes:

mount --bind file file
mount -o remount,bind,ro file

Cela doit être fait à chaque démarrage, par exemple via /etc/fstab.


3
2017-12-08 16:32



J'espère que quelqu'un umount le fichier pour obtenir à nouveau les autorisations d'écriture - whoan


Pourquoi ne pas créer une image ISO 9660, qui est en lecture seule par conception?

Montez l'image ISO et elle ressemblera à un CD-ROM, mais avec les performances d'un disque dur et les fichiers de l'image montée seront aussi protégés de la suppression que les fichiers d'un CD-ROM physique.

L'idée de graver le fichier sensible sur un CD et de l'exécuter à partir d'un CD-ROM est intéressante, en supposant que la définition du bit immuable sur le fichier ne soit pas jugée suffisante.

Son utilisation sur un CD physique présente des problèmes potentiels, notamment en termes de performances (les lecteurs de CD-ROM sont beaucoup, beaucoup plus lents que les disques durs ou les SSD). Il est probable que le CD-ROM soit retiré par un individu bien intentionné et remplacé par un autre disque auquel il doit accéder. Il est probable qu’une partie malveillante se contente de sortir le disque et de le lancer dans un four à micro-ondes (ou dans la corbeille), supprimant ainsi votre fichier. Il y a l'inconvénient de devoir disposer d'un lecteur de CD-ROM dédié au matériel uniquement pour ce fichier, et d'autres facteurs.

Mais le PO a clairement indiqué que l’objectif premier était de protéger contre la suppression accidentelle, et non contre les actes malveillants, et que le ou les fichiers en question sont sauvegardés et récupérables en cas d’accident, mais il est hautement souhaitable que le fichier être supprimé accidentellement.

Il semble que l’exécution du fichier à partir d’une image ISO montée satisferait à cette exigence.


2
2017-12-06 23:03



Root peut toujours supprimer un fichier en manipulant l'image directement. C'est juste un fichier normal qui se trouve être monté. - Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Comment alors? ISO 9660 de par sa conception est immuable. La partie effectuant cette modification devrait supprimer et remplacer le fichier ISO en entier. Pas qu'ils ne pouvaient pas faire ça. Mais ils ne pouvaient pas entrer et supprimer chirurgicalement un fichier sans une expertise considérable, même dans ce cas. Il serait beaucoup plus facile de retirer un CD-ROM physique d'un lecteur et de le lancer dans un conteneur de dépôt. ;-) - Craig
Pas besoin d'être sophistiqué - écrasez simplement le fichier image avec des zéros. - Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Je vais concéder ce point assez facilement. La mise en garde est qu'il faudrait délibérément démonter l'image et la remplacer. Un coup minutieux serait juste shred à ce point. Mais à moins que vous ne refusiez l'accès physique à la machine, il semble toujours plus facile de simplement extraire un CD physique du lecteur et de le jeter dans le benne à ordures que de démonter et d'écraser le fichier ISO, bien que ce soit facile. Et le PO a déclaré que le fichier important est sauvegardé régulièrement. Il ne s'agit donc que d'une mesure supplémentaire contre les dommages accidentels et non contre les méfaits malicieux. - Craig
J'ai indiqué comment modifier une image ISO9660 même si elle est supposée être non modifiable. Mon point est que si un bit est en écriture, root peut l'écrire. - Thorbjørn Ravn Andersen