¿Por qué es "chmod -R 777 /" destructivo?

255

Esta es una pregunta canónica sobre el permiso de archivos y por qué 777 es "destructivo".

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

Si alguna vez ha ejecutado este comando, destruirá de inmediato su sistema operativo. No estoy 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 de escritura rápido en la terminal, de repente tengo acceso bien ... ¿por qué eso hace que Linux se rompa?

linux permissions chmod samwise
fuente
2
Me quedé sin aliento cuando vi esta pregunta.
Alireza Savand

Respuestas:

344

En primer lugar, una pequeña terminología insignificante: chmodno elimina los permisos. Los CAMBIA .

Ahora el meollo del problema - El modo 777significa "Cualquiera puede leer, escribir o ejecutar este archivo" - Usted ha dado permiso para que cualquiera haga (efectivamente) lo que quiera.

Ahora, ¿por qué es esto malo?

  1. Acaba de dejar que todos lean / modifiquen cada archivo en su sistema.
    • Adiós a la seguridad de las contraseñas (cualquiera puede leer el archivo oculto y descifrar sus contraseñas, pero ¿por qué molestarse? ¡CAMBIE la contraseña! ¡Es mucho más fácil!).
    • Adiós a la seguridad de sus binarios (alguien puede escribir un nuevo loginprograma que los deje entrar cada vez).
    • Adiós a tus archivos: un usuario dirige mal rm -r /y todo ha terminado. ¡Se le dijo al sistema operativo que les dejara hacer lo que quisieran!
  2. Has cabreado todos los programas que verifican los permisos de los archivos antes de comenzar.
    sudo,, sendmaily una gran cantidad de otros simplemente no comenzarán más. Examinarán los permisos de archivos clave, verán que no son lo que se supone que deben ser y devolverán un mensaje de error.
    Del mismo modo, sshse romperá horriblemente (los archivos clave deben tener permisos específicos, de lo contrario son "inseguros" y, por defecto, SSH se negará a usarlos).
  3. Has eliminado los bits setuid / setgid en los programas que los tenían.
    El modo 777es en realidad . Entre las cosas en ese dígito principal están los bits y . La mayoría de los programas que son setuid / setgid tienen ese bit establecido porque deben ejecutarse con ciertos privilegios. Están rotos ahora.0777setuidsetgid
  4. Se ha roto /tmpy/var/tmp la otra cosa en ese dígito octal principal que se puso a cero es el sticky bit- Eso que protege los archivos en /tmp(y /var/tmp) de ser eliminados por personas que no los poseen.
    Hay (desafortunadamente) un montón de scripts de mal comportamiento por ahí que "limpian" haciendo un rm -r /tmp/*, y sin el bit adhesivo establecido /tmp puede despedirse de todos los archivos en ese directorio.
    Tener archivos rascables desaparecer realmente puede alterar algunos programas mal escritos ...
  5. Ha causado estragos en /dev /procsistemas de archivos similares y
    esto es más un problema en los sistemas Unix más antiguos donde /devhay un sistema de archivos real, y el contenido que contiene son archivos especiales creados mknod, ya que el cambio de permisos se conservará en los reinicios, pero en cualquier sistema cambiar los permisos de su dispositivo puede causar problemas sustanciales, desde los riesgos de seguridad obvios (todos pueden leer cada TTY) hasta las causas potenciales menos obvias de un pánico en el núcleo.
    Credit to @Tonny for pointing out this possibility
  6. Los enchufes y las tuberías pueden romperse, o tener otros problemas. Los enchufes y las tuberías pueden romperse por completo, o estar expuestos a inyecciones maliciosas como resultado de que se puedan escribir en todo el mundo.
    Credit to @Tonny for pointing out this possibility
  7. Has hecho que todos los archivos de tu sistema sean ejecutables.
    Mucha gente tiene .en su PATHvariable 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 (digamos makeo ls, y intente que ejecute su código malicioso.
    Credit to @RichHomolka for pointing out this possibility
  8. En algunos sistemas, chmodse restablecerán las listas de control de acceso (ACL).
    Esto significa que puede terminar teniendo que volver a crear todas sus ACL además de corregir 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 ejecutándose las partes del sistema que ya se están ejecutando? Probablemente, por un tiempo al menos.
Pero la próxima vez que necesite iniciar un programa, o reiniciar un servicio, o Dios no lo quiera, REINICIE la caja en la que se encuentra en un mundo de dolor, ya que los n. ° 2 y n. ° 3 anteriores alzarán sus feas cabezas.

voretaq7
fuente
1
Al menos en algunos sistemas /tmpse solucionaría después de un reinicio. Aunque todo lo demás parece estar roto. Al menos en VM que acabo de probar, parece que un reinicio solucionó los /tmppermisos. Debe haber algo en un script de inicio en alguna parte.
Zoredache
@Zoredache Los sistemas que usan tmpfsgeneralmente se arreglan solos, los que tienen / tmp en el disco pueden (depende de sus scripts de inicio)
voretaq7
45
+1 por señalar que setuid y setgid serían eliminados. Este es un aspecto enormemente destructivo. Intente ejecutar find / -perms -4000 -type fy find / -perms -2000 -type fver varios binarios que se basan en estos indicadores.
Kyle Smith
2
Escribir algo como "less foo.txt" no ejecutaría un archivo llamado less.txt, independientemente del bit ejecutable que se establezca. Tendría que tener el directorio less.txt en su camino y tendría que escribir "less.txt foo.txt", no es realmente algo accidental allí. Incluso si estuviera utilizando la terminación de shell, se detendría en menos y aún tendría que agregar el .txt. Para llamar a un archivo de texto aleatorio con un conjunto de bits ejecutable tendrías que ./nameoffile.txt.
The Real Bill
3
@Deji everyonese define como la unión de un conjunto que incluye el usuario propietario del archivo, los usuarios del grupo que posee el archivo, y los usuarios que no cumplan con cualquiera de esos criterios (literalmente los tres dígitos de permisos octales: User, Group, y Other). En otras palabras, cualquier usuario con acceso al sistema . ("Acceso" en este contexto podría ser una cuenta shell, que es la forma en que normalmente lo trataría, pero también incluye acceso a través de un formulario web / CGI que escribe datos en el disco: el wwwusuario ahora puede escribir en cualquier archivo del sistema , lo que significa que los visitantes aleatorios también pueden.)
voretaq7
102

Una cosa importante es que hay muchas herramientas como ssh / sudo que verifican 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 serio problema de seguridad. En mi sistema de prueba de Debian y quizás en otros, la capacidad de iniciar sesión falla, probablemente porque el binario de inicio de sesión o algo en PAM tiene verificaciones de permisos.

Por lo tanto, no es realmente que el sistema esté destruido, es que muchas herramientas están diseñadas para fallar inmediatamente cuando los permisos son incorrectos.

Si reinicia un sistema después de hacerlo, chmod 777 -R /se iniciará y podrá iniciar procesos que no tengan comprobaciones explícitas de permisos. Por lo tanto, el sistema no está realmente muerto, solo que, por diseño , es algo inutilizable .

Zoredache
fuente