¿Por qué el ARCHIVO DE CARGA DE MYSQL solo lee algunos archivos y no otros?

4

Como parte de una evaluación, estoy usando mysql para buscar en el sistema de archivos de un host comprometido. Como recordé la última vez que jugué con él, algunos archivos se pueden leer (por ejemplo, / etc / passwd) y otros no (/ etc / shells).

La documentación de mysql dice específicamente: Por razones de seguridad, al leer archivos de texto ubicados en el servidor, los archivos deben residir en el directorio de la base de datos o ser legibles por todos ... enlace

Pero ese no parece ser el caso, ya que ambos archivos tienen los mismos permisos efectivos, y la propiedad y solo el primero se puede leer con load_data () o LOAD DATA INFILE.

-rw-r--r--   1 root    root      73 Feb 13  2013 shells
-rw-r--r--   1 root    root    1.7K Oct  9 04:49 passwd

mysql> select load_file("/etc/passwd");
| load_file("/etc/passwd")
| root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh

...

mysql> select load_file("/etc/shells");
+--------------------------+
| load_file("/etc/shells") |
+--------------------------+
| NULL                     |
+--------------------------+
1 row in set (0.00 sec)

¿Cómo se realiza esta discriminación y es algo que se puede restringir aún más? (Sé que puede deshabilitar el archivo de datos de carga, pero digamos que no pudo debido a un ETL o algo así, ¿cómo aplicaría esto de forma selectiva en / etc / passwd, por ejemplo)?

    
pregunta Ori 09.10.2013 - 06:45
fuente

1 respuesta

2

Parece que este es el enigma del armero. Me "detuve" y volví a probar, pero no parecía importar.

Habilitando APPARMOR_ENABLE_AAEVENTD para poder obtener registros en denys relacionados con el armado:

vi /etc/apparmor/subdomain.conf

y actualicé la línea:

APPARMOR_ENABLE_AAEVENTD="yes"

y reinicie apparmor

ori@myamdbox:/etc/apparmor$ sudo service apparmor restart

A continuación, vuelvo a ejecutar el archivo de carga ("/ etc / shells") arriba y el registro salió:

Oct 10 04:03:13 myamdbox kernel: [85739.145281] type=1400 audit(1381374193.268:132): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/mysqld" name="/etc/shells" pid=22485 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=0

Derribar el perfil para una prueba funcionó, por lo que ciertamente es el culpable.

Para solucionarlo, simplemente abrí /etc/apparmor.d/usr.sbin.mysqld

y agregó la línea:

...

/etc/shells r, 

Y sí, funciona.

mysql> select load_file("/etc/shells");
+---------------------------------------------------------------------------+
| load_file("/etc/shells")                                                  |
+---------------------------------------------------------------------------+
| # /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
|
+---------------------------------------------------------------------------+
1 row in set (0.00 sec)

Para hacer lo contrario, solo necesito encontrar la referencia en la configuración de apparmor y eliminarla.

¡Gracias Lekensteyn!

    
respondido por el Ori 10.10.2013 - 05:27
fuente

Lea otras preguntas en las etiquetas