Вопросы Теги

Как найти соединение между интерфейсом TAP и его файловым дескриптором?

Быстрое и грубое предположение:

  • В доступе отказано. Файлы в / etc часто не могут быть изменены обычными пользователями, особенно такими пользователями Интернета, как ваш httpd. Запустите chmod -R + w / etc / openvpn , чтобы открыть для этого дыру, или выполните какую-нибудь chown вещь.

  • Команда sed недействительна. В командах номер 2-4 появилось несколько косых черт. Поскольку за s следует косая черта, косые черты используются в качестве разделителя операндов, а sed не будет работать с таким большим количеством недопустимых операндов. Измените свой sed на это:
3
13.08.2018, 04:50
2 ответа

Запись iff:, которая могла датьответ , была добавлена ​​в ядро ​​3.14 с фиксацией tun: add device name(iff) field to proc fdinfo entry, поэтому недоступна в ядре 3.13 и более ранних версиях., например, с Ubuntu 14.04LTS.

В этом случае, несмотря на то, что запросить информацию у ядра невозможно, можно запросить фактический процесс предоставить эту информацию, отследив его с помощью отладчика.

Начиная с Linux 2.6.27 доступен ioctl для запроса информации о настроенном интерфейсе tuntap:TUNGETIFF. Его использование для процесса, наследующего fd , чтобы иметь возможность запрашивать fd , чтобы получить имя и тип интерфейса(ifr_nameиifr_flags)или узнать, что устройство tuntap не было настроено. еще(EBADFD)и что он должен это сделать.

Таким образом, несмотря на то, что можно использовать gdb, это немного сложно, потому что, если среда разработки недоступна, некоторые необходимые параметры и значения должны быть известны или изменены (и могут измениться в будущем или с архитектурой ). ].Эта информация и корректировки, если они необходимы здесь:

  • определение$mallocдля 64-битных систем для обработки правильного размера возвращаемого адреса памяти :кредит принадлежит этому комментарию от SO.
  • $malloc(64):struct ifreqвыглядит как 40 байт на 64 битах, давайте использовать 64, чтобы оставаться в безопасности.
  • 0x800454d2== TUNGETIFF.
  • результат ifr_nameнаходится по смещению 0.

Вот сценарий оболочки, подготавливающий путь для каждого найденного tuntap fd для вызова gdb, вместе с собственным скриптом gdb:

tungetiff.sh:

#!/bin/sh

[ $# -gt 0 ] || exit 1
SCRIPTGDB="$1"; shift

for pid in "$@"; do
    for procfd in /proc/$pid/fd/*; do
        if [ "$(readlink $procfd)" = "/dev/net/tun" ]; then
            fd=$(basename $procfd)
            printf 'pid=%d fd=%d ifname=' $pid $fd
            gdb -batch-silent --pid=$pid -ex 'set $fd'=$fd -x "$SCRIPTGDB"
        fi
    done
done

tungetiff.gdb:

set $malloc=(void *(*)(long long)) malloc
p $malloc(64)
p ioctl($fd, 0x800454d2, $1)
set *((char *)($1+16))=0
set logging file /dev/stdout
set logging on
printf "%s\n",$1
set logging off
call free($1)
quit

Типичный пример выполнения (, вероятно, будет работать только от имени пользователя root, даже пользователь libvirt -qemu не может ptrace qemu -система):

#./tungetiff.sh tungetiff.gdb $(pgrep qemu-system-)
pid=22281 fd=26 ifname=vnet1
pid=22281 fd=30 ifname=vnet2
pid=27109 fd=26 ifname=vnet0
4
27.01.2020, 21:15

Зная файловый дескриптор 27, вы прошли бы /procпроцесс QEMU:

 $ ls /proc/<qemu-system-x86_64_PID>/fd/27

На том же уровне, что и каталог fd, находится еще один каталог fdinfo, содержащий такие детали, как этот:

$ cat /proc/<qemu-system-x86_64_PID>/fdinfo/27
pos:    0
flags:  0104002
mnt_id: 18
iff:    tap0123acdc-66

Запись iffв этом файле — это ответвительное устройство.

Ссылки

3
27.01.2020, 21:15

Теги

Похожие вопросы