Quanto è sicuro mantenere gli script di proprietà non root in /etc/init.d?

Ho un'applicazione che funziona come un demone ed è controllata da uno script in /etc/init.d
A volte abbiamo bisogno di cambiare alcuni parametri di avvio / controllo di questi script e quindi riavviare il demone. Questi script hanno solo il permesso di scrittura per l'utente root, quindi quando modifico questi script ho bisogno dei privilegi di root.

Quello che stavo pensando è che avrei dovuto rendere un utente non root il proprietario di quegli script. In questo modo solo root e un utente speciale possono modificare questi script.

È accettabile tenere alcuni file di proprietà non root nelle directory /etc/init.d?
O è assurdo, disturbare l'ordine naturale del sistema?

Ciò che viene immediatamente in mente è che un utente non privilegiato è in grado di eseguire le cose all'avvio come root , il che è desiderabile per i cracker che:

• Vuoi intensificare i privilegi di altri account
• Desideri utilizzare il tuo server per ospitare un servizio non autorizzato
• Vuoi avviare i robot IRC / Spam se il server si riavvia
• Vuoi fare un rumore metallico su una nave madre per dire "Sono di nuovo sveglio" e forse scaricare un nuovo payload
• Vuoi ripulire le loro tracce
• ... altra cattiveria.

Questo è possibile se il tuo utente sfavorito è in qualche modo compromesso, forse attraverso un altro servizio (http / etc). La maggior parte degli aggressori eseguirà rapidamente lso findsu / di tutto /etcper vedere se esistono tali possibilità, ci sono shell scritte in varie lingue che usano che lo rendono semplice.

Se gestisci il server in remoto, principalmente tramite SSH, ci sono ottime possibilità che non lo vedrai nemmeno a meno che non controlli lo script init, perché non vedrai l'output all'avvio (tuttavia, dovresti usare qualcosa che controlla gli hash di quegli script con hash noti per vedere se qualcosa è cambiato, o software di controllo versione, ecc.)

Sicuramente non vuoi che ciò accada, root ha davvero bisogno di possedere quello script di init. Potresti aggiungere l'utente di sviluppo all'elenco dei sudoer in modo che sia abbastanza conveniente aggiornare lo script, ma ti consiglio di non consentire l'accesso in scrittura senza privilegi a qualsiasi cosa in init.d

Oltre agli ottimi punti sollevati da Tim Post, aggiungerei che per un'installazione in cui più persone devono essere in grado di inviare le modifiche su un server, dovresti prendere in considerazione l'uso di un qualche tipo di sistema di gestione della configurazione.

Se, ad esempio, usi burattino, chef o cfengine, puoi fare in modo che gli utenti interessati modifichino i file localmente e quindi espellano le modifiche con la gestione della configurazione. Ovviamente il modo in cui configurarlo varierà a seconda del sistema in uso, ma se impostato correttamente includerà un software di controllo delle versioni che semplifica il ripristino di una versione precedente di un file di configurazione quando (nota: quando , non se !) qualcuno ha fatto un errore. Semplifica inoltre la copia della configurazione in un sistema di test separato, ecc.