Sin embargo, después de pensarlo un poco, no puedo pensar en por qué el código ejecutable compartido en un servidor interno no debería tener permisos 777.
Porque no solo confía en todos los usuarios, lo que podría ser razonable en un servidor interno donde "todos" los que tienen acceso deberían tener ese control, también confía en todos los procesos en ese servidor. El servidor web. El servidor SSH. El cliente DHCP. Cada tarea programada y cada servicio. Incluso los procesos que se ejecutan como "nadie" y "nogroup". Todo tipo de procesos que un atacante podría aprovechar para obtener o ampliar su acceso.
Porque si vas a ser tan descuidado en el desarrollo interno, alguien será tan descuidado en un sistema de producción o cliente, porque "así es como lo solucionamos internamente".
Porque un atacante se deleitará en encontrar ese pequeño sistema que es solo interno y no es importante ni está protegido, verá debilidades como archivos de aplicaciones web grabables, utilícelos para ingresar al sistema y comience a aprovecharlo para llegar a alguna parte. Apuesto a que las contraseñas que la gente usa en ese sistema también funcionan en otros sistemas internos más valiosos. ¿Tal vez ustedes también usan la misma contraseña de root en todos los servidores? Siempre es divertido encontrarlo.
Voy a apoyar a @gowenfawr y decir que criar mejores chimpancés es un objetivo en sí mismo aquí. (ahora extrapolaré mucho sobre su cultura corporativa)
En mi empresa de desarrollo de software, hemos visto una tendencia cada vez mayor 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:
- Una seguridad descuidada en producción pone en riesgo sus datos. Ver:incumplimiento de Equifax de 2017.
- La falta de seguridad en el desarrollo hace que los desarrolladores escriban productos deficientes. Sin embargo, la actitud de que la seguridad es importante debe provenir de la administración para brindar a los desarrolladores capacitación en seguridad y tiempo para realizar revisiones de código adecuadas, y la voluntad de priorizar la reparació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.
- Las prácticas de seguridad descuidadas en TI conducen a virus en la red que pueden generar virus en el código. Vea el famoso intento de puerta trasera de Linux de 2003 donde alguien irrumpió electrónicamente en el repositorio de código de respaldo e insertó un cambio de código malicioso, con la esperanza de que eventualmente se fusionara con 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 debe 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 legítima sobre seguridad aquí, pero parece que no la hay; esto es solo pereza. Eso no me da confianza de que el principio de privilegio mínimo se está siguiendo en el producto en sí, por ejemplo, cómo se almacenan los datos, cuántos datos adicionales se devuelven de las llamadas a la API, qué información se registra o en qué otro lugar se aplica el principio de privilegio mínimo. relevante para su producto.
A menos que el programa requiera permisos de escritura, no sé 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 permisos de lectura y ejecución, y lograría el acceso deseado.
Dado que los miembros de su equipo son los únicos que tienen 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. El ransomware podría ser un ejemplo, que es ejecutado por Alice, con permisos de usuario.
- /home/alicia/ --- (drwxrwxrwx alicia alicia)
- /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 pertenecen al grupo bob y /home/bob/ no tiene rwx global Alice no tiene acceso. Sin embargo, si Bob fuera a ejecutar el ransomware con permisos de usuario, Bob tiene rwx permisos porque /home/alice/ usa global rwx permisos Entonces, ahora los directorios de inicio de Alice y Bob serán encriptados por el ransomware.
Agregar usuarios a un grupo es bastante simple, Linux:Agregar usuario al grupo (primario/secundario/nuevo/existente). Esto agregará el nombre de usuario:alice , al bob grupo. Chown -R bob:bob donde user:group posee el directorio, recursivamente. chmod -R 750 proporcionará recursivamente rwxr-x--- permisos, para que Alice pueda leer y ejecutar dentro de /home/bob/ directorio, pero no puede escribir.
sudo adduser alice bobsudo chown -R bob:bob /home/bob/sudo chmod -R 750 /home/bob/
El principio de mínimo 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 lectura, escritura y ejecución globales, juntas ------rwx es un principio de seguridad muy malo. Esta idea se hace agregando alice al bob grupo. Ahora el usuario alice tiene r-x permisos para /home/bob/ mientras que otros usuarios fuera bob el grupo no puede, excepto root. Del mismo modo, si Bob quisiera compartir archivos con Alice, pero no quiere que Alice tenga acceso de grupo, un nuevo grupo llamado AB donde Alice y Bob están en el grupo podría ser creado. Ahora un directorio /opt/AB_share/ (rwxrwx---) se podría crear y se aplicarían los comandos anteriores. Solo aquellos dentro del AB grupo tendría acceso.