El propósito de seguridad de solicitar la contraseña del administrador para montar la partición en Linux

  

Cuando quise acceder a la partición NTFS, fedora me pidió mi contraseña de administrador para montar esa partición. ¿Porque hace eso? ¿Qué propósito de seguridad tiene?

Como todos los demás han dicho, debe ser el usuario root para montar particiones, salvo algunas excepciones especiales, como definir la partición y establecer el indicador user en la entrada en /etc/fstab .

Por qué es importante restringir esto porque el montaje puede superponer cualquier punto de montaje encima de cualquier otro directorio, o incluso solo un árbol de directorios encima de otro. Con permiso para ejecutar el montaje, podría poner /home/jeff/bin encima de /bin usando mount /home/jeff/bin /bin -o bind . De repente, todos están usando la versión de su , ls , o cualquier otra cosa que desee de mi directorio.

Como demostraría lo anterior, los puntos de montaje no necesitan estar vacíos. Todo en un directorio que está montado encima simplemente se vuelve inaccesible. Mount también es capaz de convertir casi cualquier cosa en una estructura de directorio, no solo particiones. Los sistemas de archivos de bucle invertido y las unidades de red remotas también son posibles fuentes de montaje.

Por lo tanto, en el sistema multiusuario, uno no puede recorrer toda la estructura del sistema de archivos usando mount porque rompería completamente las restricciones de seguridad y cualquier presunción de que los archivos provienen de la ubicación que espera que estén porque alguien podría simplemente monte un directorio para enmascarar otro.

Permitir que cualquier persona monte cualquier sistema de archivos en cualquier ubicación abriría una serie de agujeros de seguridad.

• Una obvia es que el controlador del sistema de archivos obtiene acceso al dispositivo subyacente. Este puede ser un hardware que el administrador del sistema no desea exponer a los usuarios.
• Otra obvia es que puede haber archivos que permitan a los usuarios obtener privilegios. Un shell root de setuid, por ejemplo. O un nodo de dispositivo que permite el acceso sin formato a la memoria o disco u otro recurso de hardware. Permitir que un usuario monte un sistema de archivos arbitrario le permite crear programas setuid / setgid arbitrarios y nodos de dispositivo .
• Un problema más sutil es que el montaje de un sistema de archivos puede crear archivos en una ubicación inesperada. Algunas aplicaciones leen archivos en ubicaciones fijas o confían en archivos donde la cadena de directorios desde la raíz hasta el archivo es propiedad exclusiva de un usuario. Montar un sistema de archivos diferente a lo largo de la ruta podría permitir al montador reemplazar archivos legítimos por contenido arbitrario. Por ejemplo, podría montar una copia de /etc con un archivo diferente passwd con una contraseña de root establecida por usted. O puede montar un directorio diferente en la parte superior del directorio principal de un usuario y proporcionar su propio .ssh/authorized_keys .
• Otra preocupación es que los controladores del sistema de archivos a menudo se escriben para el rendimiento y la confiabilidad con sistemas de archivos bien formados. Si un sistema de archivos tiene un formato incorrecto, puede desencadenar un error en el controlador que permite a quien controle el dispositivo subyacente ejecutar código en el contexto del controlador del sistema de archivos, que tradicionalmente se ejecuta en el kernel.

Puede declarar un dispositivo, punto de montaje y opciones de montaje en /etc/fstab para montar un sistema de archivos automáticamente en tiempo de arranque. Depende del administrador del sistema no poner nada "peligroso" allí, por ejemplo, no montar sistemas de archivos desconocidos en las ubicaciones del sistema, deshabilitar setuid excepto en el sistema de archivos raíz, etc.

La forma anticuada de permitir que los usuarios ordinarios monten sistemas de archivos transitorios es poner la opción de montaje user en un fstab, típicamente combinado con noauto . user implica automáticamente otras tres opciones: nosuid , nodev y noexec . Estas opciones deshabilitan los archivos setuid / setgid (esos bits no tienen efecto), los archivos del dispositivo (los nodos del dispositivo no tienen efecto) y los archivos ejecutables (el bit ejecutable se ignora, excepto en los directorios), respectivamente. Las opciones nosuid y nodev son críticas; noexec se puede deshabilitar (al agregar exec después de user ) en casi todas las situaciones. Aquí hay una línea de fstab típica para un dispositivo extraíble:

/dev/cdrom  /media/cdrom  iso9660  noauto,user,exec

Un método más moderno para permitir a los usuarios montar dispositivos extraíbles es instalar el programa pmount . Este programa tiene políticas más flexibles que fstab, que solo permite una lista predefinida. Pmount impone varias restricciones, incluido el requisito de que el dispositivo se declare como extraíble y el punto de montaje sea un directorio vacío debajo de /media .

Para los recursos de red, el enfoque tradicional para ir más allá de una lista predefinida es un automounter . El montador automático normalmente se configura para permitir a los usuarios montar solo sistemas de archivos de red (NFS, Samba), solo desde hosts seleccionados (o al menos solo dentro de un dominio), con opciones predefinidas que incluyen nodev y nosuid .

Un enfoque más moderno para permitir a los usuarios montar sistemas de archivos es mover el controlador del sistema de archivos fuera del kernel. FUSE es el estándar de facto aquí (en Solaris, Linux, * BSD, OSX). El usuario debe tener acceso al dispositivo subyacente (si corresponde), ya que todos los accesos a dispositivos se realizan mediante un proceso sin privilegios. Por el mismo motivo, un error en el controlador del sistema de archivos no comprometerá la seguridad del sistema operativo. El usuario debe poseer el punto de montaje, por lo que no podrá hacer que aparezcan los archivos donde, de lo contrario, no podrá hacer que aparezcan los archivos. Los bits setuid y setgid se ignoran. Sin embargo, es posible hacer que los archivos sean propiedad de cualquier usuario, no solo el usuario que realiza el montaje.

  

fedora me pidió mi contraseña de administrador

Como Zzz dice correctamente, solo la raíz puede montar / desmontar particiones. En realidad, solo la raíz puede hacer muchas cosas, por ejemplo, incluyendo el enlace a puertos por debajo de 1024.

Con solo un usuario root, compartir la contraseña de root se convierte en un problema. Además, habilitar el inicio de sesión directo como root podría considerarse un riesgo de seguridad más o menos similar al que uno podría cambiar el nombre de la cuenta de administrador en Windows, para desviar un objetivo común .

Ubuntu resuelve este problema generando una contraseña aleatoria para root en la instalación, y agregando usuarios que necesitan acceso de root a un grupo específico que puede ejecutar comandos a través de sudo en /etc/sudoers . El inicio de sesión de raíz se bloquea y los comandos de administración se pueden ejecutar desde un usuario normal a través de sudo , gksudo o desde el indicador de raíz a través de sudo -i .

Fedora ha recorrido la mitad del camino: el inicio de sesión de root todavía está permitido, pero los usuarios que están en el grupo wheel pueden ejecutar sudo con su propia contraseña (en lugar de root). La línea específica en /etc/sudoers que habilita esto es:

%wheel ALL=(ALL) ALL

Ahora, dos notas históricas:

• Algunos comandos en Fedora no conocen el uso de sudo y requieren root. Los comandos de la raíz de Fedora solían ejecutarse a través de su -c , que todavía ocurre en los documentos en algunos lugares, por lo que a veces necesitará la contraseña de la raíz.
• Históricamente, su significa "cambiar usuario" y el grupo de ruedas es el grupo permitido para ejecutar su .

Y algunas notas finales sobre la seguridad de Unix:

• habrás oído hablar de setuid y setgid bits. Esto permite que un proceso se ejecute en el contexto del usuario propietario y el grupo respectivamente, en lugar de quién los inició, y es la forma tradicional de permitir que los usuarios inicien procesos que necesitan alguna funcionalidad de nivel raíz.
• Ahora, en realidad, está en desuso: fedora ha adoptado las capacidades de posix con preferencia a esto, que distribuye las capacidades de root según sea necesario, lo que permite que muchos procesos se inicien de forma no root.

[¿Tiene una instalación de Windows XP y le preocupa la seguridad? : p]

  

(Opcional) Los derechos actualmente están elevados para cualquiera en el grupo de la rueda (administradores del sistema). Puede seleccionar solo usuarios particulares, por ej. de esta manera

suena bien hasta ahora. Me gustaría verificar los permisos en el sistema de archivos después de que esté montado, que no mencionan explícitamente. P.ej. ejecute "mount" y busque la opción de montaje "uid" en esta partición. Supongo que está bien, sin embargo.

Entonces, la implicación es que cualquier compromiso de su usuario de Linux puede comprometer fácilmente la instalación completa de Windows, y por lo tanto todo el sistema, tan pronto como inicie Windows. Esto no es necesariamente un gran problema. Una vez que su usuario de sudo / su se comprometa, ¡ya perdió! A menos que este sea un sistema multiusuario, una vez que su usuario esté comprometido, afectará todas las cosas importantes: las contraseñas que ingresa en su teclado, sus archivos, correos electrónicos, actividad en línea, etc. Y las vulnerabilidades de escalamiento de privilegios surgen con bastante frecuencia de todos modos. / p>

Si desea trabajar en la defensa en profundidad, puede reorganizar las particiones para que sus datos compartidos estén en una partición diferente a la de Windows XP. Esto se recomienda solo si puede hacer una copia de seguridad de todos sus datos, porque hay mucho espacio para cometer errores al reorganizar las particiones.

Alternativamente, puedes intentar lograr el mismo efecto con un script de inicio personalizado. Monte el FS completo con su opción uid = deseada, enlace monte su directorio de datos compartidos en un segundo punto de montaje, luego desmonte el original. Estoy bastante seguro de que funciona para FAT de todos modos. Espero que no haya una forma astuta de evitarlo: la gente sí usa "espacios de nombres del sistema de archivos" como una herramienta de seguridad, y no se sabe que sea mala, como chroot.

Solo la raíz puede montar particiones (a menos que se configure de otra manera). De lo contrario, cualquier persona podría hacer daño desmontando particiones, cambiando las opciones de montaje, etc.