Pregunta:
¿Podría explicar por qué un archivo compilado binario (en, por ejemplo, /usr/sbin ) tiene permiso de escritura para el usuario root ?
Para mí, esto está compilado. Lo que significa que la escritura directa no tiene uso y puede exponer el archivo a algún problema de seguridad de alguna manera.
Una secuencia de comandos (por ejemplo, un archivo bash ) puede ser grabable porque es básicamente un archivo de texto, pero ¿por qué es lo mismo para un archivo compilado donde no es realmente necesario escribir hasta donde yo sé?
Gracias de antemano por sus comentarios.
Respuesta:
Realmente no importa si los archivos en /bin (o cualquier otro directorio estándar donde se guardan los ejecutables) son grabables por root o no. En un servidor Linux que estoy usando, el root puede escribirlos, pero en mi máquina OpenBSD, no lo es.
¡Siempre que el grupo o "otros" no puedan escribirlos!
No hay ningún problema de seguridad al tener, p. Ej.
-rwxr-xr-x 1 root root 126584 Feb 18 2016 /bin/ls
Si alguien quisiera sobrescribirlo, tendría que ser root, y si es root y lo sobrescribe, entonces es
- instalando una nueva versión, o
- torpe, o
- un atacante que ya tiene permisos de root .
Otra cosa a considerar es que root puede escribir en el archivo sin importar si está protegido contra escritura o no, porque … root.
Tenga en cuenta también que "un script" es tanto un ejecutable como un archivo binario. No es necesario que un script se pueda escribir "porque es un archivo de texto". En todo caso, probablemente debería tener el mismo permiso que los otros ejecutables en el mismo directorio.
¡No vayas a cambiar los permisos de todo ahora! Eso puede causar todo tipo de estragos y potencialmente confundir a los administradores de paquetes que podrían verificar que los permisos estén configurados correctamente. También puede hacer que el sistema sea vulnerable si accidentalmente cambia los permisos de forma incorrecta en una aplicación crítica para la seguridad.
Simplemente asuma que los permisos en los ejecutables están configurados correctamente, a menos que encuentre algo que parezca realmente extraño, en cuyo caso probablemente debería comunicarse con el mantenedor del paquete relevante para verificar en lugar de comenzar a cambiar cosas.
A partir de los comentarios y en el chat , hubo una llamada para un poco de historia.
El historial de permisos sobre binarios en Linux no es nada de lo que sepa nada. Se puede especular que simplemente heredaron los permisos del directorio, o simplemente de la umask predeterminada de Linux, pero realmente no lo sé.
Lo que sí sé es que OpenBSD instala los binarios en el sistema base 1 con el modo de permiso 555 por defecto ( -r-xr-xr-x ). Esto se especifica en un fragmento Makefile en /usr/share/mk/bsd.own.mk que establece BINMODE en 555 (a menos que ya esté configurado). Esto se usa más tarde al instalar los ejecutables durante la make build en /usr/src .
Eché un vistazo al registro CVS anotado para este archivo y descubrí que esta línea en el archivo no ha cambiado desde que se importó de NetBSD en 1995.
En NetBSD, el archivo se puso por primera vez en CVS en 1993, con BINMODE establecido en 555.
El proyecto FreeBSD parece haber usado exactamente el mismo archivo que NetBSD desde al menos 1994 , y con una confirmación posterior agrega una pista en el mensaje de confirmación de que los archivos antiguos eran de la versión 4.4BSD de Berkeley Software Distribution.
Más allá de eso, el CSRG en Berkeley mantuvo las fuentes en SCCS pero su repositorio está disponible en forma de Git en GitHub 2 . El archivo que estamos dando al tratamiento forense aquí parece haber sido cometido por Keith Bostic (o alguien cercano a él) en 1990.
Entonces esa es esa historia. Si quieres el por qué , supongo que tendremos que preguntarle a Keith. Tenía la esperanza de ver un mensaje de confirmación de un cambio que dijera " esto debe ser 555 porque … ", pero no.
1 Los sistemas BSD tienen una división más estricta en "sistema base" y "paquetes de terceros" (puertos / paquetes) que Linux. El sistema base es una unidad coherente que proporciona un conjunto completo de facilidades para ejecutar el sistema operativo, mientras que los puertos o paquetes se consideran "software local" y se instalan en /usr/local .
2 También está disponible un repositorio de GitHub más completo de versiones de Unix de los años 70 en adelante.