Mettez-le sur un CD ou un DVD. Le genre inscriptible une fois, pas ceux effaçables. Ou un autre type d'appareil en lecture seule.
Ok, je suppose que vous voulez une solution logicielle, alors voici quelques idées :Vous pourriez éventuellement créer un ensemble de règles SELinux qui désactive l'appel système que chattr utilise, même pour root. Une autre possibilité serait d'utiliser les capacités :paramètre +i nécessite le CAP_LINUX_IMMUTABLE capacité, donc si vous pouvez organiser l'ensemble de limites de capacité de tous les processus pour ne pas l'inclure, alors personne ne peut modifier ces indicateurs. Mais vous auriez besoin de l'aide de init que cela s'applique à tous les processus. Systemd peut le faire, mais je pense que cela devrait être fait pour chaque service séparément.
Cependant, si vous faites cela, rappelez-vous qu'une racine habituelle peut modifier le système de fichiers à partir du périphérique brut (c'est ce que debugfs est pour), vous devez donc également empêcher cela, ainsi qu'empêcher la modification du noyau (chargement de modules). Le chargement des modules peut être empêché avec le kernel.modules_disabled sysctl, mais je ne suis pas sûr d'empêcher l'accès aux périphériques bruts. Et rendre tous les fichiers de configuration pertinents également immuables.
Quoi qu'il en soit, après cela, vous devrez également empêcher de modifier la façon dont le système démarre, sinon quelqu'un pourrait redémarrer le système avec un noyau qui permet de contourner les restrictions ci-dessus.
Il n'y a aucun moyen de le faire. QUELQU'UN sera toujours en mesure de rétablir le fichier dans un état inscriptible, à moins qu'il ne soit sur un support en lecture seule comme un CD-ROM. Vous pouvez efficacement empêcher root de le faire en utilisant les autorisations SELinux (je ne sais pas comment faire, ou je donnerais un exemple), mais l'utilisateur qui a des autorisations pourrait toujours annuler des choses.
Ce que vous voulez, c'est le contrôle d'accès obligatoire. Il vous permet de spécifier un ensemble d'autorisations que le noyau ne permettra pas d'être remplacées, même par root. SELinux est un tel système bien connu, Smack est un autre exemple et AppArmor est un troisième système de ce type. Sous Linux, ils sont implémentés en tant que modules de sécurité Linux, une installation à usage général pour contrôler l'accès en dehors du modèle de sécurité traditionnel de type UNIX. En plus des systèmes à usage général existants, vous pouvez bien sûr créer le vôtre pour un usage particulier.
Bien sûr, root a la capacité d'activer ou de désactiver l'ensemble de l'installation ou de modifier les autorisations MAC des fichiers, et certains de ces systèmes permettent même d'accorder ces capacités aux utilisateurs non root. Cependant, il est également possible, selon le système, de désactiver cette capacité. Je sais que SELinux et Smack rendent cela possible ; Je doute que tous les LSM le fassent. Une fois désactivé, le seul moyen de retrouver la capacité est de redémarrer le noyau. Vous souhaiterez alors que votre processus de démarrage désactive la fonctionnalité avant que l'accès utilisateur ne soit activé. Si votre noyau et votre processus de démarrage sont sécurisés, une telle configuration ne pourrait (du moins en théorie) être modifiée qu'en retirant physiquement le support de stockage pour le modifier.
Par exemple, si vous utilisiez SMACK, vous pourriez faire :
chsmack -a _ <file>
Cela définirait le fichier avec l'étiquette spéciale "_" qui autorise uniquement l'accès en lecture ou en exécution, mais jamais en écriture. Désormais, même root ne peut pas écrire ce fichier (une fois que SMACK a été activé et que la capacité de neutralisation de la sécurité a été désactivée, comme mentionné ci-dessus).
Cependant, vous devez également vous assurer que votre noyau est sécurisé. Par défaut, il est facile pour root de subvertir le noyau, car le noyau fait confiance à l'utilisateur root. Si root peut simplement supprimer le module de sécurité, cela n'aide pas beaucoup. Une liste de ces méthodes est ici, mais notez qu'aucune liste de ce type ne peut jamais être vraiment complète en toutes circonstances.
Enfin, selon votre situation, vous devrez peut-être sécuriser votre processus de démarrage. Pour une machine sur laquelle vous avez un accès physique exclusif, cela n'est peut-être pas nécessaire, mais pour une sécurité maximale, vous voulez vraiment des systèmes de fichiers chiffrés et un moyen sécurisé de démarrer le noyau, comme UEFI Secure Boot.