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

15

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?

Akaks
fuente
1
mala idea, no lo hagas.
ChuckCottrill

Respuestas:

17

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

Tim Post
fuente
55
tl; dr : si haces esto, el usuario no root es tan bueno como root en el próximo arranque. Estás rogando por ser pwned.
Warren Young
9

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.

Jenny D
fuente
Mantener sus scripts e incluso sus archivos de datos de configuración versionados en un sistema de gestión de configuración / versión es una excelente idea, incluso sin considerar si un sistema podría verse comprometido.
ChuckCottrill
De hecho, lo he usado para corregir errores sobre un par de magnitudes con más frecuencia que lo he usado para arreglar un sistema comprometido.
Jenny D
Muchas gracias . Porque aquí, principalmente, un usuario dedicado usa esta aplicación, por lo que sudo está funcionando bastante bien y esto es lo que hacía desde hace mucho tiempo. PERO estoy realmente muy interesado en el sistema de gestión de versiones para las configuraciones. Querida Jenny, ¿puedes darme alguna referencia para hacerlo O CUALQUIER EJEMPLO! :).
Akaks
1
Si no desea seguir la ruta completa de títeres / chef / cfengine, etc., personalmente usaría www.perforce.com. Lo usamos para ~ 100 servidores antes de que existiera Puppet y su licencia de evaluación es suficiente para un servidor. La principal ventaja es que puede retirar archivos VC'd en cualquier lugar del sistema de archivos en lugar de limitarse a una subruta. Otras opciones son joeyh.name/code/etckeeper , o usar cualquier VC combinado con scripts para mover archivos al directorio adecuado.
Jenny D