Estoy usando capistrano para implementar una aplicación web de rieles. Quiero otorgarle al usuario de implementación en el servidor web la menor cantidad de privilegios que pueda. Pude hacer todo lo que tenía que hacer como usuario sin privilegios, excepto reiniciar el servidor web.

Estoy haciendo esto en un servidor ubuntu, pero este problema no es específico para mi caso de uso (rails, capistrano, implementación), y he visto muchos enfoques para este problema que parecen involucrar prácticas de seguridad deficientes. ¿Se pregunta si otros pueden examinar mi solución y aconsejarme si es segura?

Primero, no es necesario, pero no tengo idea de por qué /etc/init.d/nginx necesitaría algún acceso (incluso de lectura) por parte de otros usuarios. Si necesitan leerlo, conviértalos en root (por sudo u otros medios), entonces yo:

chmod 750 /etc/init.d/nginx

Dado que la propiedad es la raíz del propietario, la raíz del grupo (o se puede establecer con la raíz conocida: root /etc/init.d/nginx) solo la raíz, o un usuario correctamente sudo'ed, puede leer, cambiar o ejecutar / etc / init .d / nginx, y no voy a otorgarle a mi usuario de implementación derechos tan amplios. En cambio, solo voy a darle al usuario de implementación el derecho de sudo específico para ejecutar el script de control /etc/init.d/nginx. No podrán ejecutar un editor para editarlo, ya que solo podrán ejecutar ese script. Eso significa que si alguien obtiene acceso a mi casilla como usuario de implementación, puede reiniciar y detener, etc., el proceso nginx, pero no puede hacer más, como cambiar el script para hacer muchas otras cosas malas.

Específicamente, estoy haciendo esto:

visudo

visudo es una herramienta específica utilizada para editar el archivo sudoers, y debe tener privilegios de sudoer para acceder a él.

Usando visudo, agrego:

# Give deploy the right to control nginx
deploy ALL=NOPASSWD: /etc/init.d/nginx

Comprobar elsudo man página, pero según entiendo esto, la primera columna es el usuario que tiene los derechos de sudo, en este caso, "desplegar". ALL proporciona acceso de despliegue desde todo tipo de terminales / inicios de sesión (por ejemplo, a través de ssh). El final, /etc/init.d/nginx, SOLO le da al usuario de implementación acceso raíz para ejecutar /etc/init.d/nginx (y en este caso, NOPASSWD significa sin contraseña, lo que necesito para una implementación desatendida) . El usuario de implementación no puede editar el script para hacerlo malvado, necesitaríanCOMPLETO sudo acceso para hacer eso. De hecho, nadie puede a menos que tenga acceso de root, en cuyo caso hay un problema mayor. (Probé que la implementación del usuario no podía editar el script después de hacer esto, ¡y usted también debería hacerlo!)

¿Qué piensan ustedes? ¿Esto funciona? ¿Hay mejores formas de hacer esto? Mi pregunta es similar aesta yesta, pero proporciona más explicaciones de las que encontré allí, perdón si es demasiado duplicativo, de ser así, lo eliminaré, aunque también solicito diferentes enfoques.