¿Por qué los ejecutables en eg / usr / sbin se pueden escribir por root?

¿Podría explicar por qué un archivo compilado binario (en, por ejemplo /usr/sbin) tiene permiso de escritura para el rootusuario?

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.

Un script (por ejemplo, un basharchivo) 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.

— t1m0th33
fuente

Solo para aclarar, se pregunta por qué el usuario roottiene permiso de escritura en un archivo binario. Por lo menos, ayudaría al actualizar ese paquete.

— Eric Renouf

Tenga en cuenta que los archivos irónicamente binarios son los únicos archivos que normalmente escribimos / editamos directamente en el disco. No podemos hacer eso con archivos de texto como scripts porque las modificaciones de texto implican no escribir en el archivo sino agregar bytes adicionales en el medio del archivo o eliminar bytes en el medio del archivo. Esto es imposible de hacer con fseek fwrite. Entonces, para los archivos de texto que normalmente leemos en la RAM, luego eliminamos el archivo antiguo y escribimos el contenido de la RAM en el disco (es decir, lo sobrescribimos). Además, cuando instala, mueve o reemplaza ejecutables, está escribiendo en el disco, por lo que necesita permisos de escritura.

— slebetman

@Slebetman: puede editar directamente archivos de texto. Por ejemplo, abra el archivo, extiéndalo, haga un mapa de memoria, use memmove()para mover la última parte hasta el final y abra un agujero, luego inserte texto nuevo en el agujero. O puede usar una serie de pread()/ pwrite()para hacer lo mismo.

— Zan Lynx

@EricRenouf En realidad, no se requieren permisos de escritura en el archivo binario para actualizar el paquete que lo contiene. En la actualización del paquete, no se escribe el viejo binario; de hecho, esto es imposible si el binario se está ejecutando actualmente (buscar ETXTBSY). En cambio, el binario antiguo se elimina y el nuevo binario se escribe en un nuevo archivo con el mismo nombre. Eliminar archivos no requiere permisos de escritura en ellos, simplemente en el directorio que los contiene (es decir, /usr/sbin/).

— marcelm

@marcelm: Estrictamente hablando, no solo estás usando fseek y write, estás almacenando el resto en RAM. También puede almacenar el resto en otro búfer. O puede escribir nuevo contenido en un nuevo archivo. Ninguno de los cuales le permite extender archivos de texto sin algún tipo de búfer grande.

— slebetman

Realmente no importa si los archivos en /bin(o cualquier otro directorio estándar donde se guardan los archivos ejecutables) se pueden escribir por root o no. En un servidor Linux que estoy usando, pueden ser escritos por root, pero en mi máquina OpenBSD, no lo son.

¡Mientras no sean editables por el grupo o por "otro"!

No hay problemas de seguridad que tengan, p. Ej.

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

Si alguien quisiera sobrescribirlo, tendrían que ser root, y si lo son rooty sobrescribirlo, entonces son

instalar una nueva versión, o
torpe o
un atacante con permisos de root ya .

Otra cosa a considerar es que root puede escribir en el archivo sin importar si está protegido contra escritura o no, porque ... root.

Observe también que "un script" es tanto un archivo ejecutable como un archivo binario. Un script no necesita ser escribible "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 pueden verificar que los permisos estén configurados correctamente. También puede hacer que el sistema sea vulnerable si accidentalmente cambia los permisos de manera incorrecta en una aplicación crítica para la seguridad.

Simplemente suponga 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 contactar al responsable del paquete correspondiente para verificar en lugar de comenzar a cambiar las cosas.

De los comentarios y en el chat , hubo una llamada para un poco de historia.

La historia de los permisos en binarios en Linux no es algo de lo que sepa nada. Se puede especular que simplemente heredaron los permisos del directorio, o simplemente del valor predeterminado umaskde Linux, pero realmente no lo sé.

Lo que sí sé es que OpenBSD instala los binarios en el sistema base ¹ con el modo de permiso 555 por defecto ( -r-xr-xr-x). Esto se especifica en un fragmento de Makefile en el /usr/share/mk/bsd.own.mkque se establece BINMODEen 555 (a menos que ya esté configurado). Esto se utiliza más tarde, cuando la instalación de los ejecutables durante make builden /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 colocó por primera vez en CVS en 1993, con BINMODE555.

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 ² . El archivo que estamos dando al tratamiento forense aquí parece haber sido cometido por Keith Bostic (o alguien muy cercano a él) en 1990.

Así que esa es la historia. Si quieres saber por qué , entonces supongo que tendremos que preguntarle a Keith. Tenía la esperanza de ver un mensaje de confirmación para un cambio diciendo " 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 instalaciones para ejecutar el sistema operativo, mientras que los puertos o paquetes se ven como "software local" y se instalan debajo /usr/local.}

² _{También está disponible un repositorio GitHub más completo de versiones de Unix desde los años 70 en adelante .}

— Kusalananda
fuente

Gracias por tu respuesta. El permiso de escritura es normal ya que realmente no importa como usuario root (puede hacer cualquier cosa). Pero, como realmente no importa, ¿por qué no ponemos ningún permiso de escritura si es lo mismo desde el principio? ¿Es una decisión arbitraria?

— t1m0th33

@ t1m0th33 Creo que puede ser una decisión arbitraria que alguien ha tomado, sí. Como dije, en mi sistema OpenBSD, los archivos en esas ubicaciones no se pueden escribir root.

— Kusalananda

No creo que sea una decisión consciente de nadie. El administrador de paquetes por defecto instala el archivo con los bits de permiso con los que terminaron durante el proceso de compilación; mientras compilaba el enlazador creaba los archivos con los permisos 755 porque eso es lo que obtienes cuando resta la umask de 777, y la raíz de umask (en las máquinas de compilación del proveedor del sistema operativo) tenía durante la compilación 022 porque 022 es la umask predeterminada para todos y hacer sería 222 para root sería un trabajo extra inútil.

— Henning Makholm

+1 para "¡No vayas a cambiar los permisos de todo ahora!" Veo tantas preguntas como esa en Preguntar a Ubuntu dónde lo hizo chmod -R el usuario /usro /var, y sorpresa: su sudono funciona o algo más no funciona.

— Sergiy Kolodyazhnyy

Históricamente, la ausencia de permiso de escritura para root no tendría efecto (la raíz puede modificar cualquier cosa, y ni siquiera necesita hacerlo, porque la raíz nunca obtiene un EPERM al abrir o escribir de todos modos). Me pregunto si estas cosas de 555 comenzaron porque realmente fue posible restringir la raíz (¿cuándo aparecieron los niveles seguros por primera vez, aproximadamente al mismo tiempo que 4.4BSD o principios de 386BSD / NetBSD?)