¿Por qué un programa no puede usar su propio sistema de acceso a archivos?

Durante el inicio del sistema, el sistema operativo toma el control exclusivo de muchas operaciones privilegiadas y se convierte en el controlador de acceso. La CPU y otro hardware en sí solo escucharán el proceso de confianza (el kernel) que recibió las claves del reino. Esto significa que para poder hacer cosas como obtener acceso a la mayoría de los recursos del sistema, la aplicación debe solicitar este acceso a través del sistema operativo. El sistema operativo realmente hace el comportamiento solicitado, no la aplicación. La aplicación podría intentar realizar solicitudes directas al hardware (que tendría que ser específico del hardware), pero como no es el núcleo, las solicitudes se ignorarán si intentan acceder a algo que tenga privilegios para el núcleo.

No, los permisos del sistema de archivos son exigidos por el sistema operativo.

Cuando un programa quiere eliminar un archivo, llama a la función unlink () , que inmediatamente gira el control hacia el núcleo. El kernel primero verifica si el archivo existe y luego verifica los permisos asociados con él. Si el usuario tiene permiso para eliminar (lo que generalmente significa permiso de escritura en el directorio que contiene el archivo), el kernel, mediante el controlador del sistema de archivos, realizará todas las acciones necesarias para eliminar el archivo del disco. Una vez hecho esto, el control se devuelve al programa del usuario.

Esta distinción entre acciones realizadas directamente por su programa (normalmente llamado "modo de usuario" o "dominio de usuario") y las acciones realizadas por el kernel en nombre del usuario (típicamente llamado "modo de kernel") son una característica clave de todos los sistemas operativos, no solo de Linux, y son la base de cómo se aplican las reglas del kernel, incluida la separación de procesos, la separación de privilegios, la segmentación de memoria y todo lo que el kernel es responsable de proporcionar.

Cualquier defecto o laguna que permita que un programa evite esta protección se consideraría una vulnerabilidad de escalada de privilegios , y tiene que ser arreglado para que el sistema operativo sea seguro de usar. Estos son sorprendentemente comunes, pero generalmente se solucionan rápidamente una vez descubiertos.

Con respecto a los privilegios del sistema de archivos, lo que le impide escribir su propio controlador del sistema de archivos para eludir el controlador del sistema de archivos del kernel es el hecho de que un usuario no tiene acceso directo de lectura o escritura al disco en bruto. Estos derechos están controlados (una vez más) por los permisos del sistema de archivos.

En los sistemas Linux y Unix, hay un conjunto de archivos especiales que representan dispositivos físicos, que generalmente se guardan en el directorio /dev/ . Por ejemplo, /dev/sda representa el primer disco SCSI o SATA en Linux. En BSD (incluido OSX) es /dev/disk0 .

Leer o escribir estos archivos realmente leerá o escribirá directamente en el disco, omitiendo el controlador del sistema de archivos, pero aún pasando por el kernel. Dado que estos archivos tienen sus propios permisos establecidos, el núcleo realiza las mismas comprobaciones antes de permitir el acceso al dispositivo, por lo que la seguridad permanece intacta.

Si tuviera que cambiar los permisos o la propiedad de la entrada en /dev/ para permitir que los usuarios normales accedan directamente al disco, al hacerlo, crearía (lo adivinó) una vulnerabilidad de escalada de privilegios.

En cualquier computadora no trivial (incluyendo PC, Mac, teléfonos inteligentes, tabletas, incluso la mayoría de enrutadores domésticos de gama baja, etc.), el procesador puede funcionar en dos modos o más: modo de sistema y modo de usuario. Solo el núcleo del sistema operativo se ejecuta en modo de sistema; todos los programas se ejecutan en modos de usuario (incluso los programas que se ejecutan bajo una cuenta de administrador del sistema, como root en Unix).

Cuando el sistema arranca, el kernel se carga en la memoria. Configura la MMU para garantizar que solo el kernel tenga acceso a los periféricos de hardware, que solo el código del kernel puede afectar los datos del kernel. y ese código del kernel solo puede ejecutarse a través de interfaces controladas ( llamadas del sistema ). De esta manera, solo el código del kernel puede acceder al hardware.

El kernel no proporciona ninguna forma para que el código de usuario acceda a los dispositivos de almacenamiento, o proporciona una forma que está restringida por los permisos de archivos. Por ejemplo, en Linux y en la mayoría de los sistemas Unix, hay archivos especiales en el directorio /dev que permiten el acceso directo a el disco, pero estas entradas tienen permisos que solo permiten el acceso por parte de la raíz y quizás de otros usuarios del sistema, no por aplicaciones ejecutadas por un usuario real o un servicio no central. La única forma de que los procesos sin privilegios accedan al disco es a través de la interfaz del sistema de archivos, que incluye la gestión de permisos.

Un programa no puede pasar por alto el sistema de archivos porque no tiene manera de convencer al procesador para que le permita hablar con la unidad de disco. El kernel no lo deja.

Para que sea un poco más claro que la respuesta de @AJ Henderson, tiene dos opciones para leer / escribir datos: una para pasar por las funciones del kernel / sistema, que obviamente se apegarán a la seguridad del "entorno limitado". El otro sería acceder directamente al recurso de hardware. Eso es bastante fácil en * nix: solo haga un ls en / dev / sda1 (o lo que sea que sea su disco):

# ls -l /dev/disk0s2
brw-r-----  1 root  operator    1,   2  8 Feb 16:31 /dev/disk0s2

(lo siento, en un mac aquí) Como puede ver, el disco es legible por cualquier persona con privilegios de administrador, pero solo se puede escribir por root - por lo que está de vuelta a los permisos del sistema. Y en cuanto al acceso directo al hardware, de nuevo, eso está restringido a los permisos de nivel de kernel.

Lo que estás describiendo suena como el ataque pt_chown descrito en NullCon la semana pasada . El ataque se puede usar para tomar el control de los terminales psuedo (ptys) que incluyen una pty propiedad de la raíz (uid = 0), lo que llevaría a una escalada de privilegios en una plataforma Unix. La plataforma probada y verificada fue Linux, pero especulamos que podría suceder con OS X u otro sistema operativo BSD.

El ataque se basó en un sistema de archivos del espacio de usuario, FUSE .