Póngalo en un CD o un DVD. Del tipo que se puede escribir una vez, no de los que se pueden borrar. O algún otro tipo de dispositivo de solo lectura.
Bien, supongo que desea una solución de software, así que aquí hay algunas ideas:posiblemente podría crear un conjunto de reglas de SELinux que deshabilite la llamada al sistema que chattr usos, incluso para root. Otra posibilidad sería usar capacidades:configurando +i requiere el CAP_LINUX_IMMUTABLE capacidad, por lo que si puede organizar el conjunto de límites de capacidad de todos los procesos para que no incluya eso, entonces nadie puede cambiar esos indicadores. Pero necesitarías el apoyo de init para que eso se aplique a todos los procesos. Systemd puede hacer eso, pero creo que debería hacerse para cada servicio por separado.
Sin embargo, si hace eso, recuerde que una raíz habitual puede modificar el sistema de archivos desde el dispositivo sin formato (eso es lo que debugfs es para), por lo que también debe evitar eso, así como evitar modificar el kernel (cargar módulos). La carga de módulos se puede evitar con el kernel.modules_disabled sysctl, pero no estoy seguro de evitar el acceso a dispositivos sin formato. Y haga que todos los archivos de configuración relevantes también sean inmutables.
De todos modos, después de eso, también deberá evitar cambiar la forma en que se inicia el sistema, de lo contrario, alguien podría reiniciar el sistema con un kernel que permita anular las restricciones anteriores.
No hay manera de hacer esto. ALGUIEN siempre podrá revertir el archivo a un estado de escritura, a menos que esté en un medio de solo lectura como un CD-ROM. Puede prevenir eficazmente root de hacerlo usando los permisos de SELinux (no sé cómo hacerlo, o daría un ejemplo), pero entonces el usuario que tiene permisos aún podría deshacer las cosas.
Lo que quiere es Control de Acceso Obligatorio. Le permite especificar un conjunto de permisos que el kernel no permitirá que sean anulados, ni siquiera por root. SELinux es un sistema de este tipo muy conocido, Smack es otro ejemplo y AppArmor es un tercer sistema de este tipo. En Linux, se implementan como módulos de seguridad de Linux, una instalación de propósito general para controlar el acceso fuera del modelo de seguridad tradicional similar a UNIX. Además de los sistemas de propósito general existentes, por supuesto, puede crear uno propio para un propósito especial.
Por supuesto, root tiene la capacidad de activar o desactivar toda la instalación o cambiar los permisos MAC de los archivos, y algunos de estos sistemas incluso permiten que esas capacidades se otorguen a usuarios que no sean root. Sin embargo, también es posible, según el sistema, desactivar esta capacidad. Sé que SELinux y Smack lo hacen posible; Dudo que todos los LSM lo hagan. Una vez deshabilitado, la única forma de recuperar la capacidad es reiniciar el kernel. Luego querrá que su proceso de arranque deshabilite la capacidad antes de que se habilite el acceso del usuario. Si su kernel y el proceso de arranque son seguros, tal configuración podría (al menos en teoría) cambiarse solo quitando físicamente el medio de almacenamiento para cambiarlo.
Como ejemplo, si estuvieras usando SMACK, podrías hacer:
chsmack -a _ <file>
Esto configuraría el archivo para que tenga la etiqueta especial "_" que solo permite acceso de lectura o ejecución, pero nunca escritura. Ahora, ni siquiera el root puede escribir este archivo (una vez que se haya activado SMACK y se haya desactivado la capacidad de anulación de seguridad, como se mencionó anteriormente).
Sin embargo, también debe asegurarse de que su kernel sea seguro. De forma predeterminada, es fácil para root subvertir el kernel, porque el kernel confía en el usuario root. Si root puede eliminar el módulo de seguridad, no ayuda mucho. Aquí hay una lista de tales métodos, pero tenga en cuenta que ninguna lista de este tipo puede estar realmente completa para todas las circunstancias.
Finalmente, según sus circunstancias, es posible que deba proteger su proceso de arranque. Para una máquina en la que solo tiene acceso físico, es posible que esto no sea necesario, pero para obtener la máxima seguridad, realmente desea sistemas de archivos cifrados y una forma segura de iniciar el kernel, como UEFI Secure Boot.