¿Qué tan seguro es mantener los scripts de propiedad no root en /etc/init.d?

Tengo una aplicación que se ejecuta como un demonio y está controlada por un script en /etc/init.d
A veces necesitamos cambiar algunos parámetros de inicio / control de estos scripts y luego reiniciar el demonio. Estos scripts solo tienen permiso de escritura para el usuario root, por lo que al editar estos scripts necesito privilegios de root.

Lo que estaba pensando es que debería hacer que un usuario no root sea el propietario de esos scripts. De esta forma, solo un usuario root y un usuario especial pueden editar estos scripts.

¿Es aceptable mantener algunos archivos que no sean de root en los directorios /etc/init.d?
¿O es absurdo, perturbar el orden natural del sistema?

Lo que viene inmediatamente a la mente es que un usuario desfavorecido puede ejecutar cosas en el arranque como root , lo cual es deseable para los crackers que:

• Quiere escalar privilegios de otras cuentas
• Quiere usar su servidor para alojar un servicio no autorizado
• Desea iniciar los bots IRC / Spam si el servidor se reinicia
• Quiere hacer ping a una nave nodriza para decir "Estoy despierto de nuevo" y quizás descargar una nueva carga útil
• Quiere limpiar sus huellas
• ... otra maldad.

Esto es posible si su usuario desfavorecido se ve comprometido de alguna manera, tal vez a través de otro servicio (http / etc). La mayoría de los atacantes ejecutarán rápidamente un lso findsobre / todo /etcpara ver si existen tales posibilidades, hay shells escritos en varios idiomas que usan que lo hace simple.

Si administra el servidor de forma remota, principalmente a través de SSH, existe una gran posibilidad de que ni siquiera vea esto a menos que inspeccione el script de inicio, porque no verá la salida en el arranque (sin embargo, debería estar usando algo que comprueba los hashes de esos scripts con los hashes conocidos para ver si algo cambió, o el software de control de versiones, etc.)

Definitivamente no desea que eso suceda, la raíz realmente necesita poseer ese script de inicio. Puede agregar el usuario de desarrollo a la lista de sudoers para que sea lo suficientemente conveniente para actualizar el script, pero le aconsejo que no permita el acceso de escritura desfavorecido a nada en init.d

Además de los muy buenos puntos hechos por Tim Post, agregaría que para una configuración en la que varias personas necesitan poder introducir cambios en un servidor, debe considerar usar algún tipo de sistema de administración de configuración.

Si, por ejemplo, usa puppet, o chef, o cfengine, puede hacer que los usuarios relevantes editen los archivos localmente y luego eliminen los cambios con la administración de configuración. La forma exacta de configurar esto, por supuesto, variará según el sistema que esté utilizando, pero la configuración adecuada incluirá un software de control de versiones que facilita la reversión a una versión anterior de un archivo de configuración cuándo (nota: cuándo , no si !) alguien ha cometido un error. También le facilitará copiar la configuración a un sistema de prueba separado, etc.