¿Razón para no usar chmod -R 777 en el servidor interno para el código fuente del proyecto?

  

Sin embargo, después de pensar en ello, no puedo encontrar una   razón por la cual el código ejecutable compartido en un servidor interno no debería tener   777 permisos.

Debido a que no solo confía en todos los usuarios, lo que podría ser razonable en un servidor interno donde "todos" que tienen acceso debería tener ese control, también confía en cada proceso de ese servidor. El servidor web. El servidor SSH. El cliente DHCP. Cada tarea programada y cada servicio. Incluso los procesos que se ejecutan como "nobody" y "nogroup". Todo tipo de procesos que un atacante podría aprovechar para obtener o ampliar su acceso.

Porque si va a ser tan descuidado en el desarrollo interno, alguien va a ser tan descuidado en un sistema de Producción o Cliente, porque "así es como lo arreglamos internamente".

Debido a que un atacante se deleitará al encontrar ese pequeño sistema que solo es interno y no es importante ni está protegido, ve las debilidades como los archivos de aplicaciones web de escritura, úsalos para ingresar al sistema y comienza a aprovecharlos para llegar a algún lugar. Apuesto a que las contraseñas que la gente usa en ese sistema también funcionan en otros sistemas internos más valiosos. ¿Quizás ustedes también usan la misma contraseña de root en los servidores? Siempre es divertido encontrarlo.

Voy a secundar @gowenfawr y diré que criar mejores chimpancés es un objetivo en sí mismo aquí. (ahora extrapolaré salvajemente su cultura corporativa)

En mi empresa de desarrollo de software, hemos visto una tendencia creciente de clientes que solicitan pruebas de nuestras prácticas de seguridad, no solo en los entornos de producción, sino también en nuestro proceso de desarrollo y en la TI corporativa en general. Esta es una solicitud perfectamente razonable porque:

1. La seguridad descuidada en prod pone sus datos en riesgo. Consulte: Equifax incumplimiento de 2017 .
2. La seguridad descuidada en el desarrollo lleva a los desarrolladores a escribir productos descuidados. Sin embargo, en realidad, la actitud de que la seguridad es importante debe provenir de la administración para brindar capacitación de seguridad a los desarrolladores, y tiempo para hacer las revisiones correctas del código, y la voluntad de priorizar la solución de fallas de seguridad sobre las características del cliente. Permitir prácticas descuidadas es evidencia de que la cultura corporativa no promueve la seguridad.
3. Las prácticas de seguridad descuidadas en TI conducen a virus en la red que pueden conducir a virus en el código. Vea el famoso intento de puerta trasera de Linux de 2003 donde alguien ingresó electrónicamente al repositorio de códigos de respaldo e insertó un cambio de código malicioso, con la esperanza de que eventualmente se fusionara en el repositorio principal.

Entonces, ¿es esta una decisión de la que estaría orgulloso de contarle a un cliente?

Conclusión: El principio de privilegio mínimo es uno de los principios de codificación segura más fundamentales. Es una mentalidad que debería ser parte de cualquier proceso de desarrollo de software. Se trata de hacer la pregunta "¿Es necesario debilitar nuestra seguridad de esta manera?", En lugar de "¿Alguien puede probar que esto es peligroso?". Los hackers siempre son más inteligentes que tú.

Por supuesto, si chmod 777 es necesario por alguna razón, entonces se convierte en el menor privilegio, y podría haber una discusión de seguridad legítima aquí, pero parece que no lo hay; esto es sólo la pereza. Eso no me da confianza de que se está siguiendo el principio de privilegio mínimo en el propio producto, por ejemplo, cómo se almacenan los datos, la cantidad de datos extra que se devuelven de las llamadas a la API, la información que se está registrando o el principio de privilegio más bajo donde sea. relevante para su producto.

A menos que el programa requiera permisos de escritura, estoy confundido en cuanto a por qué su compañero de trabajo usó chmod -R 777 /opt/path/to/shared/folder cuando chmod -R 775 /opt/path/to/shared/folder aún permitiría leer y ejecutar permisos, y lograr el acceso deseado.

Dado que los miembros de su equipo son los únicos con acceso al servidor, y usted confía en ellos. Tener acceso de escritura global no es necesariamente algo malo. Pero el propósito es también evitar que los programas maliciosos o no autorizados modifiquen o eliminen los archivos. Ransomware podría ser un ejemplo, que es ejecutado por Alice, con permisos de usuario.

• / home / alice / --- (drwxrwxrwx alice alice)
• / home / bob / --- (drwxrwx --- bob bob)

Para el escenario anterior, el ransomware ejecutado por Alice cifraría y sobrescribiría todos los archivos a los que tiene acceso de escritura. Dado que Alice no no pertenece al grupo bob y /home/bob/ no tiene% global rwx Alice no tiene acceso. Sin embargo, si Bob ejecutara el ransomware con permisos de usuario, Bob tiene rwx permisos porque /home/alice/ usa permisos globales rwx . Por lo tanto, ahora los directorios de inicio de Alice y Bob estarán encriptados por el ransomware.

Agregar usuarios a un grupo es bastante simple, Linux: Agregar usuario a grupo ( Primaria / Secundaria / Nueva / Existente) . Esto agregará el nombre de usuario: alice , al grupo bob . Chown -R bob:bob donde user:group posee el directorio, recursivamente. chmod -R 750 proporcionará recursivamente permisos rwxr-x--- , por lo que Alice puede leer y ejecutar dentro del directorio /home/bob/ , pero no puede escribir.

• sudo adduser alice bob
• sudo chown -R bob:bob /home/bob/
• sudo chmod -R 750 /home/bob/

El principio de menor acceso es principalmente para proteger contra usuarios malintencionados. Sin embargo, los programas maliciosos también son una preocupación muy seria. Esta es la razón por la cual la lectura, escritura y ejecución global, juntas ------rwx es un principio de seguridad muy malo. Esta idea se realiza agregando alice al grupo bob . Ahora el usuario alice tiene r-x permisos para /home/bob/ , mientras que otros usuarios que no pertenecen al grupo bob no pueden, excepto root. Del mismo modo, si Bob quisiera compartir archivos con Alice, pero no quiere que Alice tenga acceso de grupo, se podría crear un nuevo grupo, llamado AB , donde Alice y Bob están en el grupo. Ahora se puede crear un directorio /opt/AB_share/ (rwxrwx---) y se aplican los comandos anteriores. Solo aquellos dentro del grupo AB tendrían acceso.