Правило udev для защиты от вредоносной USB-клавиатуры

Удалить usbhid будет надежнее

я надеялся, что кто-то уже писал такое правило...

можно по-подробнее?

Для тех кто не вкурсе, есть дыра

Интересно также узнать, где находится и как используется ПК, на котором пользователь использует Linux, админит его самостоятельно и опасается такой изощрённой атаки. Почему бы злоумышленнику просто не вытащить HDD/SDD, если он имеет непосредственный доступ к системнику?

с чего ты взял что у злоумышленника есть непосредственный доступ?

Ещё есть забавные устройства в виде флэшки, которые подают на порт двести вольт от встроенного преобразователя . Поможет удев тебе?

Если ты точно знаешь Vendor ID и прочее своей клавы, то надёжнее будет захардкодить подключение клавы только с определёнными вводными, иначе девайс клавой не считать.

Но если у тебя клава накроется, то тут сразу глубокая задница.

Сам щаз правило не напишу, но если документацию пару часов покурить, то ты и сам напишешь.

Ну ASUS, например, заявляет защиту от напряжений до 6 кВ для десктопных плат.

Это от статики, думаю от достаточно длительной подачи хорошего тока оно не спасёт.

Если ты точно знаешь Vendor ID

а если у вредоносного устройства вдруг окажется такой же Vendor ID?

Да, но тут однозначно нужен эксперимент! :)

может просто копеечку в юсб запихать?

Я же говорю, от рута

rmmod usbhid

и все!

Его могут майнтейнеры вкомпилять статически в ядро, тк у большинства есть usb клавомышь.

вкомпилять статически в ядро

это происки АНБ!

есть дыра, благодаря которой любая флеха может сработать как клавиатура после подключения.

Как только увидишь что флеха начала вести себя как клавиатура — сразу вынимай её :-D

Гениально , да? :-)

А можно ссылку на описание этой дыры?

да это не то чтоб дыра. Просто если клаву вставить в юсб, то с нее можно набирать буковки. Вот злой хацкер флешку хитрую вставляет, а она олько по виду вся такая флешка, а в нутрях то она клавиатура и при подаче питания эта клавиатура такая набирает rm -f / ...

так нечего в дырки непонятные предметы вставлять

How to prevent BadUSB attacks on Linux desktop?
Disabling newly-connected USB input devices

с чего ты взял что у злоумышленника есть непосредственный доступ?

ну ты ж писал про воткнуть флешку в комп, стало быть человек должен находится рядом, я так понял. Или ты про другой сценарий какой-то пишешь?

Если есть физический доступ к машине, то уже ничего не поможет.
usbguard , судя по всему может помочь частично.

ACTION=="add|change", SUBSUSTEM=="usb", KERNEL=="input[0-9]*", ATTRS{idVendor}=="dead", ATTRS{idProduct}=="beef", GOTO="persistent_kbd_end"
ACTION="add|change", SUBSUSTEM="usb", KERNEL=="input[0-9]*", RUN+="disable_device.sh %k"
LABEL="persistent_kbd_end"

Ну, как-то так, если не напутал чего. Правда, не знаю, как заставить контроллер снять питание с порта, и периодически снова его подавать, иначе порт до перезагрузки будет обесточен.

Зачем спрашивать, если человек явно не в адеквате?

Вопроса же не было 'Имеет ли это смысл или я больной параноик?'. Ну хочет и хочет.

ну ты ж писал про воткнуть флешку в комп, стало быть человек должен находится рядом, я так понял.

Ну в общем есть подобный сценарий, применяемый на практике.

В атакуемую организацию подкидывают 'случайно забытых' флешек с полезной начинкой. Ну ты понял.

Хотя ественно, что сабжевый ЯуМамыЛокалхостовыйЛинуксоидКакир никому с подобным сценарием не интересен.

можешь объяснить про:

"dead"
"beef"
"persistent_kbd_end"
"disable_device.sh %k"
LABEL="persistent_kbd_end"

и как и в каких ситуациях данное правило работает?

Ты прям все знакомые тебе слова оттуда перечислил.

Надо ещё терминал открыть, а это может делаться совершенно по-разному. Такое говно сработает разве что в винде, и это использовалось некоторыми производителями мышей для запуска установки драйверов задолго до появления этих вредоносных устройств.

dead
beef

Оно работает на сферическом в вакууме линуксе. Я ж не знаю, что там у ОП за флешкоклавомышь, VID:PID надо знать. Работать должно так: если это устройство ввода с данными VID:PID, ничего не делаем, иначе выполняем скрипт. man udev в помощь.

Создаю файл /etc/udev/rules.d/usb-block с содержимым

ACTION=="add", ATTR{bIntarfaceClass}=="03" RUN+="/bin/sh -c 'echo 0 >/sys$DEVPATH/../authorized'"

ln -s /tmp/usb-block /etc/udev/rules.d/10-usb-block.rules

cp /etc/udev/rules.d/usb-block /tmp/
/sbin/udevadm control --reload

если это устройство ввода с данными VID:PID, ничего не делаем

то есть даже в /dev не будут ссылки на флешки появляться?

$DEVPATH

Это тебе не bash :) Надо env{DEVPATH}

Надо env{DEVPATH}

где это прописать? как целиком правило должно выглядеть?

Наоборот, если ты воткнешь, скажем, флешку, VID:PID которой прописаны в правиле, то она будет работать как обычно (выполнится переход на метку «persistent_kbd_end»), все прочее будет подпадать под вторую строку правила.

Как-то так:

ACTION=="add", ATTR{bIntarfaceClass}=="03", RUN+="/bin/sh -c 'echo 0 > env{DEVPATH}/../authorized'"

Не окажется. Если это внешне флэшка, то она будет прикидываться флэшкой и по вендору и по модели.

не работает

$env{DEVPATH} тоже не работает

я попробовал заместо echo 0 > env{DEVPATH}/../authorized прописать echo $devpath >/11. так файл /11 вообще не создаётся

Это тебе не bash

та часть кода как раз таки баш. точнее sh

Нет, наколько понимаю эту подстановку выполняет udev.

Именно.

оказалось надо было ATTRS, а не ATTR

{bIntarfaceClass}==«03»

С чего ты взял, что все usb устройства ввода — HID?!
Например: втыкаю web-камеру (на ней кнопка), появляется /dev/input/event13 и новое устройство в xinput. В /sys/bus/hid/devices — ничего, в udevadm info -a /dev/input/event13 про bIntarfaceClass — ничего.

Может тогда уж SUBSYSTEM=="input" или просто в xorg.conf прописать клаву и мышь и выключить добавление новых устройств — Option "AutoAddDevices" "false"

строго, параноидально говоря, USB - сама по себе большая дыра

Может тогда уж SUBSYSTEM==«input»

Не это слишком общее, лучше привязаться к конкретному порту usb. Кто первый дырку занял, тот и клава.

тот и клава

ну дак что после RUN писать?