Re: Sandbox, AV und Co.: Damit bin ich nun sicher, oder? (Sicherheits-Sammelthread)
Hey kneim,
Dass scanelf beim Kernel keine Ausgabe produziert liegt daran, dass es nur die Infos zu ELF-Binärdateien zurückliefert. Der Kernel hingegen ist kein ELF-Binary. Er schafft erst die Bedingungen für das ELF.
Bei der scanelf-Geschichte hatte ich mich undeutlich ausgedrückt. Dafür bitte ich um Nachsicht.
Es kam mir vor Allem auf das fehlende "X" bei "STK" an. Das ist der Hinweis darauf, dass der Stack nicht ausführbar ist.
"ET_EXEC" (Flag für "ausführbare eigenständige Datei") oder "ET_DYN" (Flag für "Shared Object": Mir fällt gerade keine gute Übersetzung dafür ein) sagen für sich genommen nichts über die Schutzmechanismen eines Programms (vgl. man scanelf).
Als ein Test eignet sich da besser ein ldd (zweimal ausgeführt).
Ein Beispiel auf meinem Testsystem:
bill@mahoney ~ $ ldd /bin/bash
linux-vdso.so.1 (0x00007395c4653000)
libreadline.so.6 => /lib64/libreadline.so.6 (0x00007395c41e6000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007395c3f8c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007395c3d88000)
libc.so.6 => /lib64/libc.so.6 (0x00007395c39dd000)
/lib64/ld-linux-x86-64.so.2 (0x00007395c4433000)
bill@mahoney ~ $ ldd /bin/bash
linux-vdso.so.1 (0x0000685972062000)
libreadline.so.6 => /lib64/libreadline.so.6 (0x0000685971bf5000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x000068597199b000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000685971797000)
libc.so.6 => /lib64/libc.so.6 (0x00006859713ec000)
/lib64/ld-linux-x86-64.so.2 (0x0000685971e42000)
Bitte beachte, wie sich die Adressen der eingebundenen Libraries verändern. Das zeigt, dass ASLR bei der /bin/bash tatsächlich greift.
KVM ist aber nur der Hypervisor. Du brauchst dann noch irgendwas, was das konfiguriert und aufruft. QEmu, AQEmu und LibVirt habe ich schon damit getestet. Eine Rundum-Sorglos-Lösung war keines davon.
Gruss
Bill
Die Ausgabe sieht so aus:
$ scanelf -e /bin/bash
TYPE STK/REL/PTL FILE
ET_EXEC RW- R-- RW- /bin/bash
Auf den Linux-Kernel angewendet, gab es keine Ausgabe.
$ scanelf -e /bin/bash
TYPE STK/REL/PTL FILE
ET_EXEC RW- R-- RW- /bin/bash
Auf den Linux-Kernel angewendet, gab es keine Ausgabe.
Dass scanelf beim Kernel keine Ausgabe produziert liegt daran, dass es nur die Infos zu ELF-Binärdateien zurückliefert. Der Kernel hingegen ist kein ELF-Binary. Er schafft erst die Bedingungen für das ELF.
Bei der scanelf-Geschichte hatte ich mich undeutlich ausgedrückt. Dafür bitte ich um Nachsicht.
Es kam mir vor Allem auf das fehlende "X" bei "STK" an. Das ist der Hinweis darauf, dass der Stack nicht ausführbar ist.
"ET_EXEC" (Flag für "ausführbare eigenständige Datei") oder "ET_DYN" (Flag für "Shared Object": Mir fällt gerade keine gute Übersetzung dafür ein) sagen für sich genommen nichts über die Schutzmechanismen eines Programms (vgl. man scanelf).
Als ein Test eignet sich da besser ein ldd (zweimal ausgeführt).
Ein Beispiel auf meinem Testsystem:
bill@mahoney ~ $ ldd /bin/bash
linux-vdso.so.1 (0x00007395c4653000)
libreadline.so.6 => /lib64/libreadline.so.6 (0x00007395c41e6000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007395c3f8c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007395c3d88000)
libc.so.6 => /lib64/libc.so.6 (0x00007395c39dd000)
/lib64/ld-linux-x86-64.so.2 (0x00007395c4433000)
bill@mahoney ~ $ ldd /bin/bash
linux-vdso.so.1 (0x0000685972062000)
libreadline.so.6 => /lib64/libreadline.so.6 (0x0000685971bf5000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x000068597199b000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000685971797000)
libc.so.6 => /lib64/libc.so.6 (0x00006859713ec000)
/lib64/ld-linux-x86-64.so.2 (0x0000685971e42000)
Bitte beachte, wie sich die Adressen der eingebundenen Libraries verändern. Das zeigt, dass ASLR bei der /bin/bash tatsächlich greift.
Danke für den Hinweis über KVM. Kannte ich noch nicht, sehe ich mir genauer an.
KVM ist aber nur der Hypervisor. Du brauchst dann noch irgendwas, was das konfiguriert und aufruft. QEmu, AQEmu und LibVirt habe ich schon damit getestet. Eine Rundum-Sorglos-Lösung war keines davon.
Gruss
Bill