Pregunta ¿Por qué “chmod -R 777 /” es destructivo?


Esto es un Pregunta canónica sobre el permiso de archivo y Por qué 777 es "destructivo".

No estoy preguntando cómo solucionar este problema, ya que hay un montón de referencias de eso ya en Server Fault (reinstalar el sistema operativo). ¿Por qué hace algo destructivo en absoluto?

Si alguna vez ha ejecutado este comando, casi inmediatamente destruye su sistema operativo. No tengo claro por qué eliminar las restricciones tiene algún impacto en los procesos existentes. Por ejemplo, si no tengo acceso de lectura a algo y después de un error rápido en el terminal, de repente ahora tengo acceso bien ... ¿por qué eso hace que Linux se rompa?


246
2018-02-28 21:25


origen


Me quedé sin aliento cuando vi esta pregunta. - Alireza Savand


Respuestas:


En primer lugar, una terminología menor: chmod no hace retirar permisos Eso CAMBIOS ellos.


Ahora la carne de la cuestión - El modo 777 significa "Cualquiera puede leer, escribir o ejecutar este archivo" - Usted tiene permiso dado para que cualquiera haga (efectivamente) lo que sea que ellos quieran.

Ahora, ¿por qué es esto malo?

  1. Acaba de dejar que todos lean / modifiquen todos los archivos de su sistema.
    • Dígale adiós a la seguridad de la contraseña (cualquiera puede leer el archivo de la sombra y descifrar sus contraseñas, pero ¿por qué molestarse? ¡CAMBIE la contraseña! ¡Es mucho más fácil!)
    • Bese la seguridad para sus binarios adiós (alguien puede escribir un nuevo login programa que les permite en cada momento).
    • Adiós a tus archivos: un usuario se desvía rm -r / y todo ha terminado. ¡Se le dijo a la OS que les permitiera hacer lo que quisieran!
  2. Has enojado a todos los programas que comprueban los permisos de los archivos antes de comenzar.
    sudo, sendmail, y muchos otros simplemente no comenzarán más. Examinarán los permisos de los archivos clave, verán que no son lo que se supone que deben ser y rechazarán un mensaje de error.
    similar ssh se romperá horriblemente (los archivos clave deben tener permisos específicos, de lo contrario son "inseguros" y, de forma predeterminada, SSH se negará a usarlos).
  3. Has eliminado los bits setuid / setgid en los programas que los tenían.
    El modo 777 es en realidad 0777. Entre las cosas en ese dígito principal están el setuid y setgid pedacitos
    La mayoría de los programas que son setuid / setgid tienen ese bit establecido porque deben ejecutarse con ciertos privilegios. Están rotos ahora.
  4. Te has roto /tmp y /var/tmp La otra cosa en ese dígito octal inicial que obtuvo cero es el sticky bit - Lo que protege los archivos en. /tmp (y /var/tmp) de ser borrados por personas que no los poseen.
    Hay (desafortunadamente) un montón de guiones mal comportados por ahí que "limpian" haciendo una rm -r /tmp/*, y sin el bit adhesivo puesto en /tmp  Puedes despedir todos los archivos en ese directorio.
    Hacer desaparecer los archivos de scratch realmente puede alterar algunos programas mal escritos ...
  5. Has causado estragos en /dev  /proc y sistemas de archivos similares
    Esto es más un problema en sistemas Unix antiguos donde /deves un sistema de archivos real, y lo que contiene son archivos especiales creados con mknod, ya que los cambios en los permisos se mantendrán durante los reinicios, pero en cualquier sistema que cambie los permisos de su dispositivo puede causar problemas sustanciales, desde los riesgos de seguridad obvios (todos pueden leer cada TTY) hasta las causas menos obvias de un pánico en el núcleo.
    Credit to @Tonny for pointing out this possibility
  6. Los enchufes y tuberías pueden romperse o tener otros problemas Los enchufes y las tuberías pueden romperse por completo o exponerse a una inyección maliciosa como resultado de su capacidad de escritura en el mundo.
    Credit to @Tonny for pointing out this possibility
  7. Has hecho cada archivo en tu sistema ejecutable
    Mucha gente tiene . en su PATH variable de entorno (¡no deberías!) - Esto podría causar una sorpresa desagradable ya que ahora cualquiera puede soltar un archivo convenientemente llamado como un comando (por ejemplo, make o ls, y tiene la oportunidad de conseguir que ejecute su código malicioso.
    Credit to @RichHomolka for pointing out this possibility
  8. En algunos sistemas chmod reiniciará las listas de control de acceso (ACL)
    Esto significa que puede terminar teniendo que volver a crear todas sus ACL además de arreglar los permisos en todas partes (y es un ejemplo real de que el comando es destructivo).
    Credit to @JamesYoungman for pointing out this possibility

¿Seguirán funcionando las partes del sistema que ya están funcionando? Probablemente, al menos por un tiempo.
Pero la próxima vez que necesites iniciar un programa, reiniciar un servicio o no puedes REINICIAR la caja en la que te encuentras en un mundo de dolor, ya que el # 2 y el # 3 de arriba levantarán sus feas cabezas.


335
2018-02-28 21:46



Al menos en algunos sistemas. /tmp sería arreglado después de un reinicio. A pesar de todo, muchas otras cosas parecen estar rotas. Al menos en la VM que acabo de probar aparece un reinicio arreglado /tmp permisos Debe haber algo en un script de inicio en algún lugar. - Zoredache
@Zoredache sistemas que utilizan tmpfs Normalmente se arreglan solos, los que tienen / tmp en el disco. mayo (depende de sus guiones de inicio) - voretaq7
+1 por señalar que setuid y setgid serían eliminados. Este es un aspecto enormemente destructivo. Intenta correr find / -perms -4000 -type f y find / -perms -2000 -type f Para ver varios binarios que dependen de estas banderas. - Kyle Smith
Escribir algo como "less foo.txt" no ejecutaría un archivo llamado less.txt, independientemente del bit ejecutable establecido. Necesitaría tener el directorio less.txt en su ruta y tendría que escribir "less.txt foo.txt" - no es algo accidental allí. Incluso si estuvieras usando la finalización de shell, se detendría menos y aún tendrías que agregar el .txt. Para llamar a un archivo de texto aleatorio con un conjunto de bits ejecutables, tendría que ./nameoffile.txt. - The Real Bill
@Deji everyone se define como la unión de conjunto que incluye el usuario que posee el archivo, los usuarios del grupo que posee el archivo y los usuarios que no cumplen ninguno de estos criterios (literalmente, los tres dígitos de permiso octales: User, Groupy Other). En otras palabras Cualquier usuario con acceso al sistema.. ("Acceso" en este contexto podría ser una cuenta de shell, que es la forma en que normalmente lo abordaría, pero también incluye el acceso a través de un formulario web / CGI que escribe datos en el disco: www el usuario ahora puede escribir en cualquier archivo en el sistema, lo que significa que los visitantes al azar también pueden hacerlo.) - voretaq7


Una cosa importante es que hay muchas herramientas como ssh / sudo que comprueban los permisos del sistema de archivos para los archivos de configuración clave. Si los permisos son incorrectos, estas herramientas están diseñadas para fallar, ya que esto indicaría un grave problema de seguridad. En mi sistema de prueba Debian y quizás en otros, la capacidad de inicio de sesión falla, probablemente porque el binario de inicio de sesión o algo en PAM tiene controles de permisos.

Entonces, en realidad no es que el sistema se destruya, es que muchas herramientas están diseñadas para fallar inmediatamente cuando los permisos son incorrectos.

Si reinicia un sistema después de hacer un chmod 777 -R / se iniciará y podrá iniciar procesos que no tengan controles de permisos explícitos. Así que el sistema no está realmente muerto, solo algo inutilizable por diseño.


100
2018-02-28 21:33