Mettilo su un CD o un DVD. Quelli una volta scrivibili, non quelli cancellabili. O qualche altro tipo di dispositivo di sola lettura.
Ok, suppongo che tu voglia una soluzione software, quindi ecco alcune idee:potresti creare un set di regole SELinux che disabiliti la chiamata di sistema che chattr usi, anche per root. Un'altra possibilità sarebbe usare le capacità:impostare +i richiede CAP_LINUX_IMMUTABLE capacità, quindi se puoi organizzare l'insieme di delimitazione delle capacità di tutti i processi in modo da non includerlo, nessuno può modificare quei flag. Ma avresti bisogno del supporto di init che si applichi a tutti i processi. Systemd può farlo, ma penso che dovrebbe essere fatto separatamente per ogni servizio.
Tuttavia, se lo fai, ricorda che un normale root può modificare il filesystem dal dispositivo grezzo (questo è ciò che debugfs è per), quindi dovresti impedire anche quello, così come impedire la modifica del kernel (caricamento dei moduli). Il caricamento dei moduli può essere impedito con il kernel.modules_disabled sysctl, ma non sono sicuro di impedire l'accesso ai dispositivi raw. E rendere immutabili anche tutti i file di configurazione rilevanti.
Ad ogni modo, dopodiché, dovresti anche impedire di modificare il modo in cui il sistema si avvia, altrimenti qualcuno potrebbe riavviare il sistema con un kernel che consente di ignorare le restrizioni di cui sopra.
Non c'è modo di farlo. QUALCUNO sarà sempre in grado di ripristinare lo stato scrivibile del file, a meno che non si trovi su un supporto di sola lettura come un CD-ROM. Puoi prevenire efficacemente root utilizzando i permessi di SELinux (non so come fare, o fornirei un esempio), ma poi l'utente che ha i permessi sarebbe comunque in grado di annullare le cose.
Quello che vuoi è il controllo degli accessi obbligatorio. Ti consente di specificare un insieme di permessi che il kernel non consentirà di sovrascrivere, nemmeno da root. SELinux è un noto sistema di questo tipo, Smack è un altro esempio e AppArmor è un terzo di questi sistemi. In Linux, sono implementati come Linux Security Modules, una struttura generica per controllare l'accesso al di fuori del tradizionale modello di sicurezza simile a UNIX. Oltre ai sistemi generici esistenti, puoi ovviamente crearne uno tuo per uno scopo speciale.
Naturalmente, root ha la capacità di attivare o disattivare l'intera struttura o modificare le autorizzazioni MAC dei file e alcuni di questi sistemi consentono persino di concedere tali funzionalità a utenti non root. Tuttavia, è anche possibile, a seconda del sistema, disabilitare questa capacità. So che SELinux e Smack lo rendono possibile; Dubito che tutti gli LSM lo facciano. Una volta disabilitato, l'unico modo per recuperare la capacità è riavviare il kernel. Dovrai quindi desiderare che il tuo processo di avvio disabiliti la funzionalità prima che l'accesso utente sia abilitato. Se il kernel e il processo di avvio sono sicuri, tale configurazione potrebbe (almeno in teoria) essere modificata solo rimuovendo fisicamente il supporto di archiviazione per modificarla.
Ad esempio, se stavi usando SMACK, potresti fare:
chsmack -a _ <file>
Ciò imposterebbe il file in modo che abbia l'etichetta speciale "_" che consente solo l'accesso in lettura o in esecuzione, ma mai in scrittura. Ora anche root non può scrivere questo file (una volta che SMACK è stato attivato e la capacità di override della sicurezza è stata disabilitata, come menzionato sopra).
Tuttavia, devi anche assicurarti che il tuo kernel sia sicuro. Per impostazione predefinita, è facile per root sovvertire il kernel, perché il kernel si fida dell'utente root. Se root può semplicemente rimuovere il modulo di sicurezza, non aiuta molto. Un elenco di tali metodi è qui, ma tieni presente che nessun elenco di questo tipo può mai essere veramente completo per tutte le circostanze.
Infine, a seconda delle circostanze, potrebbe essere necessario proteggere il processo di avvio. Per una macchina in cui hai l'unico accesso fisico, questo potrebbe non essere necessario, ma per la massima sicurezza vuoi davvero file system crittografati e un modo sicuro per avviare il kernel, come UEFI Secure Boot.