Perché LOAD FILE di MYSQL legge solo alcuni file e non altri?

4

Come parte di una valutazione sto usando mysql per esplorare il filesystem degli host compromessi. Come mi è sembrato di ricordare dall'ultima volta che ho giocato con esso, alcuni file possono essere letti (ad esempio / etc / passwd) e altri non possono (/ etc / shells.)

La documentazione di mysql dice esplicitamente: Per motivi di sicurezza, durante la lettura dei file di testo che si trovano sul server, i file devono risiedere nella directory del database o essere leggibili da tutti ... link

Ma non sembra essere il caso, dal momento che entrambi i file hanno le stesse autorizzazioni effettive, e la proprietà e solo la prima possono essere letti da 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)

Come viene eseguita questa discriminazione ed è qualcosa che può essere ulteriormente limitata? (So che puoi disabilitare l'infile dei dati di caricamento, ma diciamo che non è possibile a causa di un ETL o qualcosa del genere, come applicheresti selettivamente su / etc / passwd per esempio.)

    
posta Ori 09.10.2013 - 06:45
fonte

1 risposta

2

Sembra che questo sia l'enigma di apparmor. Avevo "fermato" l'apparmor e ho ripeterlo, ma non sembrava importare.

Abilitazione di APPARMOR_ENABLE_AAEVENTD in modo da poter ottenere i registri sui denis relativi agli apparmor:

vi /etc/apparmor/subdomain.conf

e aggiornato la riga:

APPARMOR_ENABLE_AAEVENTD="yes"

e riavviato apparmor

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

Riesco quindi a caricare il file load_file ("/ etc / shells") sopra e il registro è fuoriuscito:

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

Abbattere il profilo per un test ha funzionato, quindi è certamente il colpevole.

Per risolvere il problema ho semplicemente aperto /etc/apparmor.d/usr.sbin.mysqld

e ha aggiunto la riga:

...

/etc/shells r, 

E sì, funziona.

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)

Per fare l'opposto, ho bisogno di trovare solo il riferimento nella configurazione di apparmor e rimuoverlo.

Grazie Lekensteyn!

    
risposta data 10.10.2013 - 05:27
fonte

Leggi altre domande sui tag